Paul D. Smith writes: > "Albert D. Cahalan" <[EMAIL PROTECTED]> 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. _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
