David McNab wrote:
>Hi all,
>
>I'd be interested in people's opinions on a proposal for standardised
>source structure.
>
I added autobuild@handhelds.org because that was a list we started just
for discussing this topic.
http://www.handhelds.org/mailman/listinfo/autobuild
>For every package on the feeds, make it a principle to upload a source
>tarball as well. So for example, if someone is porting Xchat, and
>releasing xchat_x.y_arm.ipk, then one would also release
>xchat_x.y_arm.tar.gz.
>
>As for source packages, what do people think of:
>
>1. Standardised xcomp toolchsin, possibly the old /skiff workhorse
>
> Safe to assume that (virtually) everyone compiling for iPaq will
> have an i386-based linux desktop system. I also feel it safe if we
> 'legislate' that cross-compilation from i386-linux be the standard
> compilation method
>
Given the age of the old /skiff workhorse, and the non-standard place it
gets installed, I would prefer we aim for a newer toolchain. One
problem with the old toolchain is that C++ exception handling is quite
broken.
I propose we aim for gcc 3.x, for suitably stable value of x.
I do not want to mandate what people use for the own development, but
when we set up an autobuild system, it is going to be using a particular
toolchain and so all the source in the autobuild system is going to be
compiled with that toolchain. Not everyone is going to use a
cross-building toolchain, and presumably not everyone is going to cross
from x86. It would be great to have alpha->arm and ppc->arm as well as
x86->arm and arm->arm.
As much as some of us hate the x86 architecture, we need to keep in mind that it is the reference platform for Linux development.
>2. Standard tree
>
> All source packages to be rooted in /usr/src/familiar, so that if one source
> package refers to another one (eg uses its headers, or even runs
> one of its scripts), then it'll find what it needs
>
I am very unhappy with build systems that hardware absolute paths.
Using a standard environment variable that points to the top of the
build tree would be much better. Or using relative pathnames, although
that is quite fragile. What is used for Debian and RPM builds?
>3. Dependencies
>
> The 'configure' script to check on presence of any other source
> packages needed.
>
With the caveat that configure scripts should ideally work in a
cross-build environment,
>4. 'install' make target
>
> This target, after verifying (and perhaps doing) the compile/link,
> will:
>
> * copy all applicable headers/libs to /skiff toolchain (if
> applicable, say, if src package constructs a library)
> * construct a 'shrink-wrapped' ipkg, perhaps put it into
> /usr/src/familiar/ipkgs. Also, update the 'Packages' file in
> this directory, so the directory can be used as a feed
> * if the package builds a compiler, then that compiler gets
> installed into /skiff
>
Sounds good, except for the use of absolute pathnames.
>5. './configure' to assume toolchain is in /skiff
>
>6. tricky one - automatically run make on dependencies
>
>Lastly - going right off into extremes - the ipkg upload script could
>require and receive a source tarball and signature for the tarball,
>as well as just the ipkgs as it does presently. Upon receipt of a
>signed tarball, the upload host could spawn a background process which
>unpacks the tarball, runs configure, tries to make it and then
>constructs the ipkg. Generated binaries to be diff'ed against
>submitted binaries, and package automatically rejected if they're not
>the same. All output from configure and make to be emailed back to
>package author.
>
The autobuild system needs to be able to build and install packages in
an order that will satisfy the dependences.
>
>Your thoughts?
>
>Cheers
>David
>
Thanks for posting your thoughts on the subject.
I want to remind everyone that a handhelds.org build system will not
just happen, we need the involvement of the community to shape the
design of the system and to help implement that system. It might be
nice if we can agree to clone or copy and edit the system used by
debian, emdebian, red hat, etc., but I do not feel that it is a
requirement if it does not fit out needs.
Jamey
Received on Thu Mar 14 13:59:53 2002
This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 08:45:19 EDT