public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Craig Burley <burley@gnu.org>
To: g77-alpha@gnu.org, egcs@cygnus.com, gcc2@cygnus.com
Subject: Require GNU Make Somehow?
Date: Fri, 01 May 1998 16:49:00 -0000	[thread overview]
Message-ID: <199805012119.RAA24803@melange.gnu.org> (raw)

One problem I've seen a lot is people configuring for separate
source and build directories, then forgetting to use GNU make.

The result is often a bug report that, at first glance (especially
to me, since I'm still just learning how these things work),
seems to be a "real problem", but is easily addressed by asking
the person "are you using GNU make".

To cut down on these kinds of problems, would it be possibly
to find a reliable, sure-fire way to detect and report this
situation ASAP to the user, using very clear language?

I'm thinking of something like this:

  # ../sourcedir/configure ...
  <configure does its work>
  # make ...
  Sorry: you are not using GNU make, FOOBAR make, or BLETCH make,
    and most other variants of make are known to have problems
    with configurations that have separate build and source
    directories.  Please retry with a version of make that is
    known to work.
  Exit 1
  #

Whether it's even desirable is, I would think, issue #1.  I'd
sure like it, just to cut down on the bug reports I get.

If "yes", #2 is probably how to do it in the way that is most
certain to get the "right" answer.

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:

  -  Detect that source and build directories are different

  -  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

Ideally, it'd be easy for a "knowledgable" user to edit the
makefile setup to allow a not-known-working make to work
on that setup.

Also, just how to get the makefile setup to do its rejecting
regardless of the target(s) specified on the command line
is something I can't figure out offhand.  Maybe just handling
the "common" targets is fine; maybe just putting explicit
dependencies on a check-for-known-working-make target is fine;
I don't know.

Opinions on the desirability, at least?

        tq vm, (burley)

             reply	other threads:[~1998-05-01 16:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-05-01 16:49 Craig Burley [this message]
1998-05-01 17:18 ` Joe Buck
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=199805012119.RAA24803@melange.gnu.org \
    --to=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).