Re: bug work-around?

[Albert D. Cahalan]

Paul D. Smith writes:
> "Albert D. Cahalan" <address@hidden> writes:

>> What I really want is a CFLAGS default that the user can
>> override, except that "-fpic" is always added when compiling the
>> library.
>
> I don't think this will do what you want, then, even if it didn't
> crash.  Command-line overrides take precedence over variable settings,
> even target-specific variable settings.  You'd have to do this:

Never mind that it's target-specific. I expected that a "+="
would not count as setting the variable. It's already set,
and I just want to add some more stuff to it.

Oh well. Feature request: ability to make "+=" survive user settings.

>   $(LIBOBJ): override CFLAGS += -fpic
>
> although I'm not sure if that actually works or not :).
>
> Typically what one does is _NOT_ use CFLAGS for this; as per the GNU
> standards you use a different variable in the makefile to store C
> compiler flags and you let users have CFLAGS for their own use.  Then
> you just put both variables into the compile line.
>
> Often you leave the debug/optimize switches in CFLAGS so users can
> override them easily.

**sigh** OK, will do.

> As for a workaround, there's nothing really elegant I can think
> of that doesn't involve recursion.
>
> That's what has always bothered me about Miller's paper: he makes
> non-recursive make all sound very cool, but when it comes to actual
> thoughts about _how_ to implement something like this in a moderately
> complex environment (which most are these days, what with auto* tools,
> gettext, etc. etc.) there's mainly a lot of hand-waving... :).

I found that the auto* stuff was greater in size than all of procps,
was slow, and tended to cause scripts to get installed in /usr/bin
instead of executables installed in /bin.

The recursive Makefile I had before would fail to build stuff.

Now I have a non-recursive make, and damn is it ever fast.
Mostly I didn't use the automatic dependencies. I cheat a
bit, sometimes making stuff depend on a few extra headers.
It's great to have a "make tar" that can grab all the right
files without any need to "make clean" first. It's great to
have a "make clean" that runs nothing but a single "rm".

I think that the "moderately complex environment" is something
to avoid. Do you REALLY need the auto* stuff? Careful coding with
an occasional #define might do the job; Xenix and Ultrix are dead.

If traditional make isn't well suited to non-recursive use,
then you could ship something that is. I can't rely on users
to install the many 3rd-party make substitutes, but I could
rely on an extra command if you shipped it with make. I think
you're well aware of the general consensus wish list; tokenized
syntax and losing the tab/space distinction would be a start.
Most likely you've heard it all before, many times over.

BTW, not knowing if this ever got fixed: last time I tried,
there were problems when creating symlinks. Make needs to
do lstat() instead of (or in addition to) stat(). It's also
nice to take the worst-case of mtime and ctime.