[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [BusyBox] [RFC] build system change: support building in
From:       Larry Doolittle <ldoolitt () recycle ! lbl ! gov>
Date:       2004-09-30 15:17:25
Message-ID: 20040930081725.A32529 () recycle ! lbl ! gov
[Download RAW message or body]

> Don't you want to first create a build directory, and then you configure busybox inside
> this directory, creating config files etc.
> The Makefile can the be copied to this directory and built from there.
> Then the source directory is a parameter, not the build directory
> which means less changes if you build several configurations.

That is my preference.  I'm used to building other packages like this:

tar -xvzf $REFERENCE/foo-1.0.tar.gz
mkdir foo-1.0-native
cd foo-1.0-native
../foo-1.0/configure --prefix=$HOME/bin
make install
cd ..
mkdir foo-1.0-arm-linux
cd foo-1.0-arm-linux
CC=$TARGET-gcc ../foo-1.0/configure --prefix=$EMBEDDED_ROOT arm-linux
make install

Note that the source tree is completely untouched by the configure and
build process; the tree could be on CD-ROM, read-only NFS mount, owned
by another user, etc., and the build will still succeed.  This is a
big deal.

Busybox expects more customization than most other software at the
configure step, but ideally it would still fit the general pattern.

OTOH, _anything_ that separates the binary from the source tree
is better than what we have now.  I guess I agree with the first
post, suggesting that patches of this scope should be postponed
until after 1.0.

       - Larry


_______________________________________________
busybox mailing list
busybox@mail.busybox.net
http://codepoet.org/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]