[CFT][patch] buildsys touch-up and standalone applets
Bernhard Fischer
rep.nop at aon.at
Thu Feb 23 10:48:14 UTC 2006
On Tue, Feb 21, 2006 at 03:09:34PM -0500, Rob Landley wrote:
>On Tuesday 21 February 2006 10:28 am, Bernhard Fischer wrote:
>> On Wed, Feb 15, 2006 at 03:17:14PM -0500, Rob Landley wrote:
>> >On Wednesday 15 February 2006 9:45 am, Bernhard Fischer wrote:
>> >> Hi,
>> >>
>> >> The attached patch
>> >> - fixes parallel builds (make -j) to work again.
>> >> - uses less resources for the buildsystem itself.
>> >> - adds a (very) rough proposal for building standalone applets.
>> >> See "Build options" Standalone applets.
>> >> I changed coreutils/true and editors/* so you can try these as
>> >> standalone.
>> >
>> >Questions:
>> >
>> >1) I'm trying to bundle up the 1.1.1 release. Is this something that
>> > should go in for that, or for 1.1.2? (I'd prefer 1.1.2.)
>>
>> I don't want to maintain the patch out of the tree for too long
>> (furthermore it even fixes the non-IMA compilation of the lib).
>
>Understood. I can try to narrow it down by cherry picking the parts I
>understand and agree with, the way I'm doing with the big MacOS X patch.
>(It's more work on my end, but if the project needs it...)
I'm attaching the buildsys-touchup *without* the standalone proposal:
INSTALL | 21 +-
Makefile | 346
+++++++++++++++++++++----------------
Rules.mak | 312
+++++++++++++++++++++------------
applets/Makefile.in | 20 --
applets/install.sh | 3
archival/Makefile.in | 16 -
archival/libunarchive/Makefile.in | 96 ++++------
console-tools/Makefile.in | 27 --
coreutils/Makefile.in | 16 -
coreutils/libcoreutils/Makefile.in | 44 ----
debianutils/Makefile.in | 14 -
e2fsprogs/Makefile.in | 44 ++--
editors/Makefile.in | 35 +--
findutils/Makefile.in | 15 -
init/Makefile.in | 15 -
libbb/Makefile.in | 100 +++++-----
libpwdgrp/Makefile.in | 54 ++---
loginutils/Makefile.in | 19 --
miscutils/Makefile.in | 27 --
modutils/Makefile.in | 15 -
networking/Makefile.in | 29 +--
networking/libiproute/Makefile.in | 110 ++++-------
networking/udhcp/Makefile.in | 91 ++++++---
procps/Makefile.in | 14 -
scripts/config/Makefile | 10 -
shell/Makefile.in | 26 --
sysklogd/Makefile.in | 14 -
util-linux/Makefile.in | 79 +++-----
28 files changed, 784 insertions(+), 828 deletions(-)
>
>> >2) I can sort of see wrapping sed, but I'd rather fix our sed invocations
>> > to be portable to RH 7.2 and MacOS X (which I think we now have). Why on
>> > _earth_ are you wrapping mkdir and cp?
>>
>> It doesn't really have any considerable side-effects but makes it
>> possible to transparently use e.g. d:\there\my_copy.exe instead of "cp".
>>
>> Is there a specific reason you dislike the wrapping of these two
>> commands?
>
>It's not a strong objection in this particular case, but I dislike
>infrastructure in search of a user. I dislike unnecessary complexity that
>serves no current purpose, but I also have a lot of experience with "way back
>when before we knew what we wanted to do, people wrote all this speculative
>code, and now it's getting in our way and we have to tear it out to get to
>something simple we can then expand on to meet the current needs".
>
>Been there, done that, many times. I like simple. I like simple a lot. Add
>the new functionality when there's a NEED for it, please. Even when the
>speculative code turns out to be along the general lines that new users need
>(which is generally blind luck when it happens), it was never tested, has
>probably bit-rotted since, and universally turns out to be more work to learn
>how to use, debug, and hook the new thing up to than simply adding it when it
>was needed would have been. (Right now, if nobody's depending on CP to the
>point where we haven't even got a way to test it, then we don't know that a
>year from now direct references to cp won't have snuck in. Other than "be
>vigiliant", gee, one more thing to try to keep in our heads while reviewing
>patches. Not a plus.)
>
>It's a "general principles" thing. This is a small example of it that doesn't
>do a noticeable amount of harm by itself, but it also obfuscates the code to
>meet the current needs of exactly zero users. (People reading through the
>makefile for the first time have to look up where $CP is defined to see
>whether or not it's been replaced then they have to stop and try to
>understand whether there was a reason for it or not. If there's no reason
>for it, we shouldn't do it just if for no other reason than to save the
>readers from trying to figure out whether there was a non-obvious reason we
>did something that pointless.
Please let me know that you dislike something like that beforehand, i.e.
when i start adding that stuff to the buildsys without using it. It
saves time and nerves for both of us :)
>
>This one's small enough that it's entirely possible for you to feel more
>strongly than I do, and if you really want it in I'll live. Maybe there's
>some way to add a make.tests to the test suite that tests this code path (and
>serves as an example usage)? That would make me feel better...
>
>> >3) I see you touched confdata.c, reenabling something that was #ifdefed
>> > out. Can you explain why?
>>
>> Short variant: m == standalone
>>
>> The proposed patch uses the "m"odular state of KConfigs tristate to
>> denote a standalone applet.
>
>Our configuration system is already intimidating, and you want to make it so
>that every single possible applet is a tristate?
yes. It's simple and users are used to it since the kernel has the same
approach.
In the kernel '<*>' is builtin (same for busybox) while '<m>' is
no-builtin. If you dislike the letter 'm' it's very easy to change that
to a capital 'S' for Standalone.
>
>For each app we can choose not to build it, or we can build it static and
>monolithic, static and standalone, normal and monolithic, normal and
>standalone, with libbusybox and monolithic, with libbusybox and standalone.
>
>You're offering three choices. That's seven. (I really don't look forward to
>the bug report of some guy who selects "modular" for insmod because it's in
>modutils.)
It's alot of choisec, but we want to also please the users to some
extent, don't we?
Personally i think that it's better to have a relatively complex
buildsystem (busybox' buildsystem is not complex, imo. Look at Columbus
or gaussian or the like. _These_ buildsystems are intimmidating :)
>
>If our configuration system wasn't copied from the kernel and didn't already
>have code for "m", would you consider adding "m" the logical thing to do?
>(While of course leaving other packaging choices like static and libbbusybox
>off to the side?) This strikes me as a bad case of "if you have a hammer,
>everything looks like a nail". The desire to use "m" because it's there, not
>because it's right. (And M doesn't stand for "monolithic". Y stands for
>monolithic. Right.)
>
>I could be wrong about this, but it so far hasn't struck me as a good user
>interface for dealing with our current set of packaging choices.
>
>You'll have to add a "make allmodconfig" to be like "make alldefconfig" to be
>a starting point for standalone applet building, unless you want somebody who
>wants all modular applets to go in and switch the state of every one by hand.
>Whereas if "standalone applets" is one switch then you do "alldefconfig" and
>then switch on the one switch. (Just like you do for a static build.)
We can have that easily with the tristate approach, really. Just one knob
and all applets are standalone.
>
>> >Why are you worrying that some of our config symbols might wind up equal
>> > to "m"? We don't support modular builds. Are you suggesting adding
>> > support for
>>
>> We do support modular builds (see the patch).
>>
>> >modular builds as a way of doing make standalone? I was thinking of a
>> > simple
>>
>> Yes, exactly.
>>
>> >packaging choice, you seem to want some strange hybrid approach in which
>> >people might want to build a bundled busybox for some things and
>> > standalone applets for others and this is common enough that they
>> > shouldn't run two builds to do it but should understand how to configure
>> > menuconfig to do both at the same time...
>>
>> I don't understand what you are saying in the above paragraph. Please
>> explain.
>
>I can see people wanting the monolithic thing we've been doing. And I can see
>them wanting all standalone applets. I expect both of those will be common.
>
>But if people want a mix of them it seems kind of likely that they'll want a
>static mdev for the initramfs, a dozen networking apps that share a custom
>stripped down libbb (because the network interface is optional on this unit
>and when it's not installed you don't want the support code), and then the
>monolithic busybox but that one should not be linked against libbb to make it
>easier to use it on a rescue disk...
>
>And the "m" thing makes that sort of thing harder to do, not easier.
I agree to disagree :)
>
>> The proposed approach is that a user can select which applets she wants
>> to have built-in and which ones she wants as standalone applet.
>> Built-in == y
>> Standalone == m
>
>It's more work to configure such a system.
Not sure, but it certainly gives the most choice to the user.
>
>Especially since one of the pending things I've got planned is porting the
>miniconfig patch to 1.1.2, meaning managing different lists of apps should
>get easier.
>
>> >> I tested it with make-3.81beta4 and tried my best to workaround bugs in
>> >> make-3.80.
>> >
>> >What about make 3.79.1 in Red Hat 9? (In 1.2 we can abandon support for
>> > older stuff, but the 1.1.x line supports the 2.4 kernel and that means
>> > building on systems that used it.)
>>
>> I haven't tried, but i'd expect that the patch doesn't introduce any new
>> functions which were not there before.
>>
>> Can you perhaps install a make-3.79 in /opt/make-3.79 on morris? I don't
>> have a box which is ancient enough to still have that version of make
>> installed..
>
>I have image files of Red Hat 7.3 and Red Hat 9, both of which I run under
>qemu. They tar up to about 453 and 526 megs respectively, I can throw them
>somewhere if you'd like...
Please cp it onto morris, i'll grab it from there.
>
>> >Do you think I could I get the cleanup part and the make standalone part
>> > as two separate patches? It looks like half the lines this patch touches
>> > are things like the removal of .o from names, which is separate (and
>> > nice, and 1.1.1 material).
>>
>> If we agree that the non-standalone part (i.e. the fixes and
>> simplifications) can go into 1.1.1, then i'll drop the standalone
>> proposal for now and only put the rest in for 1.1.1, ACK?
>
>Cool.
Attached.
Statistics with the attached patch for defconfig (mainly due to the
gc-sections):
$ ls -las ../busybox.oorig/busybox.orig busybox.new
924 -rwxr-xr-x 1 0 0 939320 Feb 23 11:03 ../busybox.oorig/busybox.orig
912 -rwxr-xr-x 1 0 0 927444 Feb 23 11:02 busybox.new
$ size ../busybox.oorig/busybox.orig busybox.new
text data bss dec hex filename
923911 12356 1047364 1983631 1e448f ../busybox.oorig/busybox.orig
913595 12340 1048516 1974451 1e20b3 busybox.new
Please test with your setup. Ok with you for me to ci?
>
>> So yes, for the standalone stuff I can of course wait until you created
>> the busybox_1_1_1_stable branch.
>>
>> PS: I'm attaching a slightly updated version 02b of the whole patch just
>> for reference
>
>Umm... Lemme finish reviewing the sed-with-nulls patch first. Hopefully I
>can get to this later this evening...
yea, sure
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.buildsys-touchup.02c.diff.bz2
Type: application/octet-stream
Size: 19601 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20060223/992cb29b/attachment.obj
More information about the busybox
mailing list