Re: Require GNU Make Somehow?

[Craig Burley <burley@gnu.org>]

>> One problem I've seen a lot is people configuring for separate
>> source and build directories, then forgetting to use GNU make.
>
>Some makes are bad enough that building in the same directory doesn't
>work either.  The correct autoconf way of doing things seems to be to
>run tests on the make that is found, to see if it has problems.

Eek, well, let me explain a bit more what I'm concerned about.

If joe luser is stuck with a make so buggy that even building in
the same directory doesn't work, I'm hoping that he is already
aware of the deficiencies or will suitably address them as soon
as he discovers them.

But, right now, I'm a bit worried (and maybe too much so) that,
for example, the cleaning up I've done of the g77 configure and
build procedures for g77 0.5.23 (which will be based on gcc 2.8)
will start "breaking" for people who have "basically working"
makes, perhaps even working well enough to have previously
worked in build-separate-from-source builds.  Ideally I'd like
to forestall a flood of bug reports from various systems, each
looking menacingly different from the other, all of which turn
out to be "oops, gotta use gmake", though I think it's too late
for me to try and do that in g77, especially since it's best done
in gcc/egcs and other "top-level" products.

>>   # ../sourcedir/configure ...
>>   <configure does its work>
>>   # make ...
>>   Sorry: you are not using GNU make, FOOBAR make, or BLETCH make,
>
>No, because the next release of FOOBAR make may fix the bug.  The
>other is that many people have GNU make installed as gmake; if so,
>the generated makefile might try to feed itself to gmake.

(Actually the wording was intended to say "you are not using one of:
GNU make; FOOBAR make; or BLETCH make", which goes to show how
hard it is to write unambiguously.  Even so, of course, the next
release of FOOBAR make might add a *new* bug.  ;-)

Basically I was just looking for whether it would be a) worthwhile
and b) possible to, up-front, distribute products and packages
with whatever knowledge we happen to possess at the time that
a given version, or variant, of make will *not* work on
a particular configuration -- knowledge encapsulated such that,
if the user attempts the buggy thing, he gets a nice, quick,
clear diagnostic saying "this won't work because..." rather than,
50 minutes into the build, "don't know how to build gcc/f/runtime/foo",
which will trigger a bug report 99% of the time or so.

The latter sentence, "if so, the generated makefile might try to
feed itself to gmake", I'm not sure how to interpret.  If you mean
we could design this proposed mechanism so that, instead of complaining
and exiting, it complained (maybe) and tried to find a GNU make
to continue the process, then that's a rather interesting idea!

>> My guess is that doing it "right" means modifying autoconf,
>> maybe automake, and the variations gcc/egcs might use that
>> aren't "vanilla", to do the following:
>
>No mods to autoconf or automake would be needed.  Adding new stuff to
>configure.in should be enough.  configure.in can ask for any test it
>wants; autoconf provides a fairly general mechanism for executing a
>command and seeing if it successful.  The user might see
>
>Testing 'make' to see if VPATH works ... no
>Sorry, can't build with --srcdir different from the build directory.
>You'll need a better make program, such as GNU make.
>
>Or
>
>Testing 'make' to see if VPATH works ... no
>Testing 'gmake' to see if VPATH works ... yes
>************ IMPORTANT! *******************
>************ IMPORTANT! *******************
>You *must* build with gmake rather than with make!!!!!
>************ IMPORTANT! *******************
>************ IMPORTANT! *******************

Right, this is definitely worth thinking about, though it's a
bit "friendlier" in some ways and less-so in others than what I
was thinking about.  My idea was less about producing more stuff
for the user who is doing things "right" to read, but something
more like a thing for the user who does the wrong thing to
quickly, effectively, and clearly "stub his toe" on.

E.g. I'd like to "catch" the case where people just have scripts
that do "../sourcedir/configure ...; make ...", in which case
they don't see the warnings.  Ideally they'll look for them
if the build crashes 50 minutes and 50KB of output later, but
when we're also outputting messages like "mv: cc1obj: Not found"
by the handful and expecting people to ignore them, it doesn't
surprise me that sometimes users feel they need only worry about
the last 20 or so lines before the crash-point when looking for
the cause of, or reporting, a build-time crash.

>>   -  Detect that source and build directories are different
>
>Easy to do in configure.in

Agreed.  Now, if there was a little boilerplate toe-stubbing
code I could stick into g77's configure.in that would stay nice
and quiet *except* when a different-directory configuration
was being made by a known-bad make, I'd love to know about it!
Presumably something to put into the generated Makefile, for example.

One thought I had was to simply produce a gnuMakefile, or whatever
that name is, instead of a Makefile, as the normal output of
the configuration process in *that* case (the different-directory
case), and to produce a "dummy" Makefile with "stub" targets and
the "@echo" statements that generate the nice diagnostic.

But I don't like this solution because, surely, there are non-GNU
makes that do implement VPATH and what-not correctly, and it's
hardly fair to give their users the impression that it doesn't
"work" just because it doesn't read gnuMakefile in preference to
Makefile.

(Maybe I should be asking some kind of "GNU tools" mailing list.
Forget the name of the one(s) I'm on, since I rarely see email
come from them.)

>>   -  If so, produce a makefile setup that "slides through" just
>>      fine when processed by a known-working make, but that
>>      produces a diagnostic like the above when processed by
>>      any other make
>
>Better to just have configure fail if make is not powerful enough
>(telling people what their options are).

In that case, they'd either have to put gmake in their path early
enough as `make', or be offered a way to override the default
`make' with a command name/path of their own choosing, to cause
configuration to work.

So, again, I'd still be a little worried about the case where
they do that (e.g. "MAKE=gmake ../sourcedir/configure ...") but
later "forget" about the requirement and just type "make",
or forget to make sure their path is still set up correctly.

I don't mind one bit if the ideas you are suggesting are implemented
without worrying about these nits of mine, because IMO that'd solve
most of the problems anyway, and I'm not even clear on how many
more times this problem is going to keep happening.

Guess I have a bit of a belt-and-suspenders mindset towards safety,
plus a vivid imagination when I get bug reports from people who
see buggy behavior in g77 on configurations almost exactly identical
to mine, but I can't reproduce the problem at all, since, often,
when it is finally learned what the problem is, it's a very subtle
configuration or library mismatch problem that stemmed from some
kind of build problem.

But, imagination aside, the "oops, forgot to use gmake" problem is
real.  I got *two* reports in one day that I think were due to that,
from two different g77 alpha testers.  Each of them sent their bug
reports to me privately instead of to the list -- in my experience,
that means they just didn't want to embarrass me in front of the
other testers (g77 alpha testers are *incredibly* polite, at least
on that list) -- and, when I couldn't offer any help (since I
couldn't reproduce the problem), one of them later followed up with
"oops, my fault, forgot to use gmake that one time", so I assume
that was the case with the other person as well.

So, I'd like to, at the very least, move the discovery of that
mistake up much earlier in time so people waste less time waiting
for the computer to discover the problem.  A general rule of thumb
I like to operate by is: make the computer do the repetitive,
trivial memorization kinds of work, let the human do the reasoning
and be allowed to forget things sometimes.  Remember that gmake
is required instead of make on a particular one of the five
systems one might be supporting in a given instalation really
is a job for the computer, ideally.

Kind of like that "build directory is subdirectory of source
directory" bug situation, I think it's always a good idea, when
a programmer knows some combination of user-controllable settings
won't work right, to at least try and ensure that the user gets
told "this won't work" as clearly and as soon as possible after
engaging those particular settings.

This philosophizing is probably overkill for this particular issue,
but I find it's useful to keep in mind when designing all sorts
of systems, to avoid unnecessary problems down the line, so
maybe it'll be worthwhile advice to somebody.

        tq vm, (burley)