Hi all,

mbm (correct me if I'm wrong) expressed the wish to remove everything not needed to build the firmware from the buildroot, and suggested that the cross-compile toolchain could be provided separately for the package building, so we have to find a new way to build packages...

Admitting a new package building tool wasn't really a good idea and following the thread about it with PolarWolf, I made a package building tree with only subdirs and Makefiles like PolarWolf suggested with the following disgressions: · Makefile will only fetch source, patch, extract and call ipkg/rules in the source tree to build the packages
· ipkg/rules will call ipkg-build to build the package(s) by itself, avoiding the need for ipkg-buildpackage
· ipkg/rules rely on a shared Makefile.inc that defines most of the variables used to cross-compile. If (when) the toolchain is to be provided separately, only this file should be adjusted

I'm not really sure it's enough and would like to hear from you...

By the way, checking-out OpenEmbedded,  you can find there's a new target here for your favorite router.

--
Nico

Hi Nico,

Interresting stuff, I think I'll go have a deeper look when I get home.

Something that I noticed in your directory structure, btw, is the presence of libpthread. Libpthread is compiled together with the rest of uClibc, i't just isn't installed into openwrt by default. To make your packaging life easier, you could just as well pick that library from the buildroot, and package it. Just as I have, basically (I needed libpthreads for maradns). Just a thought.

I'll get back to you with real input ASAP.

Hi PolarWolf,

This is a dirty hack to package buildroot stuff the same way other packages are made. In this case, the tarball only contains an ipkg directory structure with rules / control.

Theese packages (kmod-*, libpthread, wl...) should have been the only ones built from the buildroot. I guess some of them (like netfilter extensions) are intimely linked with the firmware release they were built for. They should share a common version number identifying from what buildroot version they came.

I'm wondering what you, mbm and others are thinking about all this...

--
Nico

I still have to take a closer look, but it looks interresting. Whether or not I'll adopt it, I don't know, I have this inertia of leaving a way of working when I'm used to one :-)

One question I have for you already is how this mechanism deals with dependencies. There's software which expects to be linked against certain libraries (which have to be mipsel too!), or expects header files to exist. An example is openswan, which really wants to be compiled and linked against gmp. Those two are currently seperate packages. So how to deal with these? I mean, if someone decides to compile openswan, should gmp be automagically kicked off too? Currently, I do all the dependency resolving by hand. I have ipkg/rules put the generated header and library files away into some central directory somewhere (which looks kinda like $STAGING_DIR), and then move to the bit of software that needed it, add CFLAGS to point to the proper locations of headers and libraries, etc. Lots of work and lots of maintenance. Have you taken this into account when you designed this system, or have any ideas to resolve it? And from curiosity, how does someone else deal with issues like these?

I do something similar in my package build environment (a very poor thing compared to yours and Nico's, of course).  I actually use separate small directory trees for the header files and libraries associated with each dependency (e.g. I have a libssl directory containing a lib directory and an include/openssl directory). And, like you, I fix compiler and linker search lists by hand to add in these directories. In my case, I maintain those trees manually (copying files from build areas to the dependency directory).

It seems like a good idea to actually use a single directory for all the dependencies (a view of the target root but with files necessary for building instead of files to be installed).  Something like this could well be standardised in the package build environment. The only disadvantage I can see is that it would be possible to successfully build something without realising the required dependencies and so leave them out of the ipkg dependency list.  That will only be discovered by user testing.

However, I do not think it is necessary to build prerequisite components automatically.  To use your example: I don't think that building openswan should automatically build gmp.  That level of dependency can be handled by the builder manually and solving the general problem would be quite difficult.

Graham

Dependencies are (not really) handled at 2 levels : · in the top Makefile : this gives package subdirs dependencies, telling that libpcap must be built before fprobe for example ;
· in the ipkg/rules file : the build targets depends on a BUILD_DEPS variables. I usually put header files in it, so that the build process should abort if theese files could not be found.

I install all development stuff directly in STAGING_DIR, so I don't have to pass extra header and library search pathes. Reading both your posts, I had the funny idea to use ipkg and development packages. Since ipkg package installs are relocatable, why not provide development packages and let ipkg do the dependency work at build time ?

--
Nico

Hi all,

I'm back with my third attempt at providing a solution for package building. I've uploaded a minimal buildtree, so you can see what it looks like. This is basically an enhanced version of the last one, with the following changes : · .ipk packages are now created in a ./packages directory, ready for ipkg-make-index'ing ;
· subdirs have moved in a ./sources directory ;
· Makefiles in subdirs only declare packages, names, version, urls... and include a shared Makefile.inc with all the common rules ;
· development packages have been introduced, they usually contain header files and static libraries ;
· Makefiles now have ipkg-install and ipkg-remove targets, which install packages in OpenWRT's STAGING_DIR or remove them.
Voilà

--
Nico