Nov 27 2008
How-To: Add a Package to PADS
This article will discuss how to add a package to PADS. The documentation on this in the WARP docs is, to say it politely, sparse. This article will discuss the matter in much greater detail. It will discuss the fundamentals of what is required to add a software package to PADS and integrate it into the load build and menuconfig. After reading this you should be able to add your own software packages to pads.
This article will use the 1.1.0.62 version of PADS and the libao package as an example. If you wish to follow along with this article, you should download the 1.1.0.62 version of pads and the libao package. To get these things, do the following. All of the paths listed in this article assume you have done the following, adjust your path accordingly if you are using your own PADS version or location.
[user@localhost ~]$ svn co http://svn.pikatech.com/pads/distro/tags/1.1.0.62/ ./1.1.0.62
[user@localhost ~]$ cd 1.1.0.62/package
[user@localhost package]$ svn co http://svn.pikatech.com/pads/extra_packages/libao ./libao
There are 3 things required for each software package you wish to add. First you should have a folder with the name of your software package in the package folder. For this example that would be ~/1.1.0.62/package/libao. In that folder you require two files, one always called Config.in and the other called folder_name.mk, in this case libao.mk. If you look in ~/1.1.0.62/package/libao you will see these two files.
The file called Config.in is what the menuconfig functionality of PADS (using ncurses) uses to add your package to the menu. If you look at the Config.in file you will see the following:
config PADS_PACKAGE_LIBAO
bool “libao: a cross platform audio library”
default y
help
Libao is a cross-platform audio library that allows programs to
output audio using a simple API on a wide variety of platforms.
The first line, with the config just names the package. This name must be unique for every package in the packages folder. The second two lines set whether the package should be selected by default, y is selected and n is not selected, in the menu and the text that is displayed next to it in the menu. The last part, the help section is what is displayed for the package if the user selects the help option in menu for your library. Well everything looks good, let’s run make menuconfig and check it out.
Our libao library isn’t there, what’s the deal? The reason for this is that any package you want to add to the menu has to be added to the master Config.in file found in the base of the ~/1.1.0.62/package/ folder. Let’s add it to the “Applications” item for now, just as an example. So we just add it in the list like so:
comment “Applications”
source “package/sqlite/Config.in”
source “package/php/Config.in”
source “package/libao/Config.in” <— Added this line
Now we run make menuconfig again, and voila our package appears. Notice that it is selected by default and the text describing it appears in the list just as we described above. If you select help for it, you will also see the help text listed above. The package is also marked with NEW as this is the first time make menuconfig has been run with that package added. The next time you run it, the package will not be marked as new.
Now that we have added the package to the menu and set it to be build, let’s look at the file that actually builds the package, libao.mk. I will walk through this file section by section explaining what it all does. The thing to remember about the mk files is that they essentially work like a Makefile. Many of the concepts are the same. The first section sets some variables that will be used in the rest of the file. This section is as follows:
#Check if we are using WARP board
ifeq ($(strip $(PADS_WARP)),y)
#Define version of your package
LIBAO_VER=0.8.8
#Define where your packaging will be compiled
LIBAO_DIR=$(BUILD_DIR)/libao-$(LIBAO_VER)
#Define the name of package to be downloaded
LIBAO_SOURCE=libao-$(LIBAO_VER).tar.gz
#Define the distribution site
LIBAO_SITE=http://downloads.xiph.org/releases/ao
#Define a method to uncompress downloaded package
LIBAO_UNZIP=tar xfz
endif
The LIBAO_VER sets the version number of the package we want. It is useful to do it in this way because if I want to upgrade to a newer version of this package, I just need to change this number, everything else stays the same, and I can just run make libao to compile the new version. The LIBAO_DIR variable sets the name of the folder where we will do our compilation of libao. The LIBAO_SOURCE variable sets the name of the source code package we will download and extract. The LIBAO_SITE variable sets the location we will download the package from. The LIBAO_UNZIP variable sets the method to extract the source code. In this case we use “tar xfz” because the source code is in a tarball.
The next lines are a set of configure options, we will discuss those shortly. The next section is as follows:
#Rule to define how to obtain your package (wget in this case)
$(DL_DIR)/$(LIBAO_SOURCE):
$(WGET) -P $(DL_DIR) $(LIBAO_SITE)/$(LIBAO_SOURCE)
#Uncompress the package, then mark the directory with “.unpacked” file
$(LIBAO_DIR)/.unpacked: $(DL_DIR)/$(LIBAO_SOURCE)
$(LIBAO_UNZIP) $(DL_DIR)/$(LIBAO_SOURCE) -C $(BUILD_DIR)
touch $(LIBAO_DIR)/.unpacked
This is the part that downloads our source code and unpacks it using the variables we defined above. There are two other variables here that are defined as part of the PADS environment variables. The DL_DIR variable sets where we will download the packages to, in this case it would be ~/1.1.0.62/dl/ folder. The BUILD_DIR variable sets where we will build the packages, in this case it would be ~/1.1.0.62/build_warp/ folder. Other defined environment variables in the PADS build system can be found here. The first part downloads the source code based on the values we set earlier and the second part extracts that source code. We now have our source code and are ready to configure our code. The next lines show the sections of the mk file related to configuring the code.
LIBAO_CONFIGURE_OPTS=–host=powerpc-linux –prefix=$(TARGET_DIR)/usr \
–disable-alsa –disable-alsa09 –disable-oss –disable-sun –disable-esd \
–disable-irix –disable-nas –disable-macosx –disable-pulse –disable-arts
# Configure the package, once done, mark the folder with “.configured”
$(LIBAO_DIR)/.configured: $(LIBAO_DIR)/.unpacked
cd $(LIBAO_DIR); ./configure $(LIBAO_CONFIGURE_OPTS)
touch $(LIBAO_DIR)/.configured
libao-configure: $(LIBAO_DIR)/.configured
libao-config: $(LIBAO_DIR)/.configured
The first variable here, LIBAO_CONFIGURE_OPTS, sets the values we pass to the configure script. The next section runs the configure. You can see we change into our source code directory and run the configure script with our defined options. We then mark it with a hidden file, .configured, so that we only run the configure script the first time we make libao. The last two lines are just different ways to call configure within libao. You could call them from the ~/1.1.0.62/ folder. The next section is our compile directives.
#Compile and install if applicable
libao: $(LIBAO_DIR)/.configured
$(MAKE) -C $(LIBAO_DIR)
$(MAKE) -C $(LIBAO_DIR)/src install-strip
$(MAKE) -C $(LIBAO_DIR)/include install
#Compile and install if applicable
libao-all: $(LIBAO_DIR)/.configured
$(MAKE) -C $(LIBAO_DIR)
$(MAKE) -C $(LIBAO_DIR) install
There are two ways to compile the code here. Only one is necessary, the one called the name of the package, libao, and it is the default. In our case the first make compiles and installs the binaries and include files only. The second makes and installs everything. The last part of the file is our clean directives.
#If you want to start over
libao-clean:
$(MAKE) -C $(LIBAO_DIR) clean
$(RM) -f $(LIBAO_DIR)/.configured
libao-distclean: libao-clean
$(MAKE) -C $(LIBAO_DIR) uninstall
$(MAKE) -C $(LIBAO_DIR) distclean
$(RM) -rf $(LIBAO_DIR)
#This section will bring it up to defaults
libao-dirclean: libao-distclean
$(RM) -rf $(DL_DIR)/$(LIBAO_SOURCE)
There are three levels of doing clean here. The first just runs the clean directive of the package and removes our .configured tag so we can start our compile and configure again. The second one adds to the first by calling the uninstall directive of the package and removing our extracted source code folder. The third adds to the second by removing our downloaded source code as well. Call this if you want to start from scratch.
ifeq ($(strip $(PADS_PACKAGE_LIBAO)),y)
TARGETS+=libao
endif
This last part is what is called by the top level Makefile in the ~/1.1.0.62/ folder to make our package. I will speak more about this in a further article next week that will explore some more advanced options to what was discussed here. This includes:
- package dependencies
- alternate package source retrieval methods
- setting package build order
Tips, Tricks and Random Thoughts
- The easiest way to start creating your own software package is to copy one already made and then modify as needed for your package. For example if you wanted to create a library software package for libeg, for example, you could copy libao as your basis. Just change the folder name to libeg instead of libao and rename libao.mk to libeg.mk. Then in the two files, change all instances of libao to libeg and LIBAO to LIBEG and you are halfway done.
- If you need help with a package, you can post to the PIKA Forum on PADS, and somebody, probably me, will help you out.
- Library files tend to be easier to port than applications into PADS. Any GNU library is especially easy to put into PADS as they are built to cross compile.
- Some applications will just not cross compile. In that case read here for an optional method to get the application onto the WARP.
I hope this article helps get you on your way to creating your own software packages in PADS for the WARP. Remember to tune in next week for additional coverage of this topic.
Skar