Conditionally compiled lib*/*.o [was: Re: [PATCH] ...]

[Rob Landley]

On Saturday 13 May 2006 9:32 am, Bernhard Fischer wrote:
> On Sat, May 13, 2006 at 09:04:44AM -0400, Robert P. J. Day wrote:
> >On Sat, 13 May 2006, Bernhard Fischer wrote:
> >> On Fri, May 12, 2006 at 05:52:41PM -0400, Robert P. J. Day wrote:
> >> >  i'm *reasonably* certain that this patch should be applied.
> >>
> >> If you want to cleanup this area, then please make generally sure to
> >> check against make-3.79.1 (as long as this is regarded a requirement),
> >> make-3.80 and make-3.81.
> >> The three cases which have to be tested with each of these versions is
> >> a) building in-tree
> >> b) building in empty obj-dir (-f Makefile)
> >> b) building to empty obj-dir (O=)
> >
> >actually, that brings up a point someone mentioned earlier.  that
> >funky little patch i posted earlier for automating the multi-part
> >source files involved invoking a "call" inside an "eval", which i
> >recall someone suggested didn't work (or didn't work properly) in
> >earlier versions of make.
> >
> >does anyone here know if that's an issue?  *should* that work?
> >because if it's not supported or broken in earlier versions, then it's
> >obviously not a good patch.
>
> If it doesn't work for all versions of make(1) the maintainer want's us
> to support, then yes, it's broken and should not have been applied.
>
> Someone may disagree, but it gets increasingly painful to support
> anything older than make-3.80.

Despite the fact that people managed to build projects in the 1970's, 1980's, 
and 1990s with older tools, we don't seem to be capable of it.

> We have very special requirements due to the way we build certain parts of
> the project. 

In that case our makefiles are just too darn complex, and need to be 
simplified.

I can make a sed script that will generate make file sections for the C files 
that generate multiple .o files.  That's trivial, and gnu make is _designed_ 
to work with generated makefiles.

As for the shared library, we have two options:  1) Have it be a separate 
target with separate logic.  We either link against a ".a" file or a ".so" 
file, but either way we should only build the one we need, based on a single 
config switch.  2) Remove the shared library entirely as something we just 
shouldn't be doing.

> These requirements are 
> seldomly seen/imposed unto make in other projects.

Busybox is not special.  Busybox is a configurable package of command line 
utilities.  That's it.  This is not brain surgery.

> Some cleanups and simplifications we could do in our buildsystem require
> somewhat current versions of make.

Such as?

> I, personally, would require the current, stable release of make (3.81
> as the time of this writing), but i'm aware that the installed base of
> 3.80 is very big (the majority of distros use/ship it).

Older versions of busybox built with older versions of make.  We went to c99 
for portability reasons, so we could declare things like int_32t in a 
portable manner, and because older versions of gcc sucked at producing 
non-x86 code.  What portability advantages would a newer version of make 
have?

> One thing that would be good to have is to think about a way to extract
> the objects (functions) which are exported by libbb/ */lib* (e.g.
> libunarchival et al.) and are actually *used* by the set of selected
> applets.

In theory this is part of automatic dependency generation, which is a can of 
worms I've stayed away from so far.  (I prototyped some code back in 
february, but didn't check it in.)

Rob
-- 
Never bet against the cheap plastic solution.