%% "Albert D. Cahalan" <[EMAIL PROTECTED]> writes: adc> Paul D. Smith 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: adc> Never mind that it's target-specific. I expected that a "+=" adc> would not count as setting the variable. It's already set, and I adc> just want to add some more stuff to it. User's command line settings always trump settings in the makefile, regardless of whether they're set with "=", "+=", ":=", or any other way. See the GNU make manual, section "How Variables Get Their Values". adc> Oh well. Feature request: ability to make "+=" survive user adc> settings. See the GNU make manual, section "The 'override' Directive". >> 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... :). adc> I found that the auto* stuff was greater in size than all of adc> procps, was slow, and tended to cause scripts to get installed in adc> /usr/bin instead of executables installed in /bin. I don't know what this means: auto* tools install in /usr/local/... unless the user specifies otherwise. The other comments are true, but at the same time auto* saves me a lot of work in GNU make. Other packages may well have different needs of course. adc> Now I have a non-recursive make, and damn is it ever fast. adc> Mostly I didn't use the automatic dependencies. I cheat a adc> bit, sometimes making stuff depend on a few extra headers. adc> It's great to have a "make tar" that can grab all the right adc> files without any need to "make clean" first. Automake already does that. In a fully compiled workspace, with test files and backup files and all sorts of other flotsam lying around, I run: make distcheck and it (a) rebuilds any files that are out of date, (b) creates a source tarball (and a .bz2 file as well if I want it) with only the actual source files, no extra files, (c) unpacks the tarball again in a temporary location, (d) cd's to that directory, (e) makes a subdirectory for a remote build, (f) runs configure, (g) runs make, (h) runs "make check" to invoke the regression tests, (i) cleans up, and (j) finally tells me whether the thing is ready to go. That's worth a lot, to me. adc> It's great to have a "make clean" that runs nothing but a single adc> "rm". I only run "make clean" about once a... well, almost never, really, I guess. I either just rerun make and it rebuilds what's missing or I remove my CVS workspace and check out a new one. The speed of "make clean" is never something I've considered a problem. adc> I think that the "moderately complex environment" is something to adc> avoid. Do you REALLY need the auto* stuff? Careful coding with an adc> occasional #define might do the job; Xenix and Ultrix are dead. That's fine for some packages, but I consider GNU make a "bootstrap package" and thus I strive to keep it as portable as possible; you can still build GNU make with a K&R compiler, for example. You need make before you can build most of the other software that allows an older system to be usable. adc> If traditional make isn't well suited to non-recursive use, then adc> you could ship something that is. I can't rely on users to adc> install the many 3rd-party make substitutes, but I could rely on adc> an extra command if you shipped it with make. I think you're well adc> aware of the general consensus wish list; tokenized syntax and adc> losing the tab/space distinction would be a start. Most likely adc> you've heard it all before, many times over. Sorry, you're looking in the wrong place. That's not GNU make's function. There are plenty of other good build tools that already exist and fulfill these niches and I'm quite uninterested in inventing a new one just to give it the imprimatur of a GNU tool. Anyway, even if I did, how could you rely on it if you can't even rely enough on people having the current version of GNU make to avoid a bug workaround :)? I'm willing to provide extra features to GNU make which are _optional_ and disabled by default (if they change the functioning of GNU make so that it's no longer backward compatible in a way which seems important): allowing the user to specify a different character than TAB as a command prefix, for example, would be an enhancement I would consider (although the default would always be TAB). "Tokenized syntax" is a much more complex problem, which involves either a complete rewrite and re-envisioning of the way make works, or a quick hack which may or may not be satisfactory. adc> BTW, not knowing if this ever got fixed: last time I tried, adc> there were problems when creating symlinks. Make needs to adc> do lstat() instead of (or in addition to) stat(). No. The POSIX standard is quite clear on this _AND_ there are many environments which rely on make using stat() and _not_ lstat() even in the presence of symlinks. Changing GNU make to use lstat() would break those existing users. Again, it is quite possible to allow this to be an optional feature enabled through a pseudo target or somesuch. adc> It's also nice to take the worst-case of mtime and ctime. Ouch!! This would be a disaster! Consider unpacking a tarfile! Why do you think this would be a good thing? -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
