From: Joe Buck <jbuck@synopsys.com>
To: burley@gnu.org (Craig Burley)
Cc: g77-alpha@gnu.org, egcs@cygnus.com, gcc2@cygnus.com
Subject: Re: Require GNU Make Somehow?
Date: Fri, 01 May 1998 17:18:00 -0000 [thread overview]
Message-ID: <199805012256.PAA20798@atrus.synopsys.com> (raw)
In-Reply-To: <199805012119.RAA24803@melange.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.
> # ../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.
> 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! *******************
> - Detect that source and build directories are different
Easy to do in configure.in
> - 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).
next prev parent reply other threads:[~1998-05-01 17:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-05-01 16:49 Craig Burley
1998-05-01 17:18 ` Joe Buck [this message]
1998-05-01 19:37 ` Craig Burley
1998-05-02 10:47 ` Dave Love
1998-05-02 14:30 ` Craig Burley
1998-05-03 22:02 ` Jim Meyering
1998-05-04 12:46 ` Craig Burley
[not found] <egcs.199805020042.UAA25532@melange.gnu.org>
1998-05-02 1:35 ` Todd P. Whitesel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199805012256.PAA20798@atrus.synopsys.com \
--to=jbuck@synopsys.com \
--cc=burley@gnu.org \
--cc=egcs@cygnus.com \
--cc=g77-alpha@gnu.org \
--cc=gcc2@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).