Re: bug work-around?

[Paul D. Smith]

%% "Albert D. Cahalan" <address@hidden> 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 <address@hidden>          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