all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: kai@emptydomain.de, rms@gnu.org, storm@cua.dk, emacs-devel@gnu.org
Subject: Re: make bootstrap fails.
Date: Wed, 4 Feb 2004 13:36:53 -0600 (CST)	[thread overview]
Message-ID: <200402041936.i14Jaru03370@raven.dms.auburn.edu> (raw)
In-Reply-To: <FAAC3D8A-5732-11D8-B132-00039363E640@swipnet.se> (jan.h.d@swipnet.se)

There would seem to be four possibilities:

1.  CDPATH=

2.  export CDPATH=

3.  use the shell command `unset CDPATH' at various places all over
    Makefile.in. 

4.  systematically do `cd ./dir' rather than `cd dir' at every single
    occurrence of cd in all Makefiles.  That includes the case where
    dir is a variable expanding to a relative name.

Clearly, 3 and 4 require both some initial work and carefulness when
subsequently making changes to the Makefile.  So I believe they should
only be considered if we agreed that both 1 and 2 are too simplistic.
Note also that, even without any change, problems only develop with a
user CDPATH _not starting with a colon_.  Personally, I would not want
to be using such a CDPATH and certainly not export it, because it
seems like a dangerous thing to do.  Richard has already stated that
he does not believe that the problem is worth a substantial amount of
work.

There are currently no instances of use of the make `export' directive
in Makefile.in.  Maybe it was avoided because some make's do not
understand it.  Hence I am afraid that (2) might break some make's
even if CDPATH is unset.  Maybe somebody can assure me that this fear
is groundless.

(1) definitely seems to work for GNU make and might work for other
makes, maybe even all makes.  Importantly, it will not make the
situation _worse_ for _any_ make.  On the other hand (3) is used at
some (but not enough) places in Makefile.in already, so maybe (1)
will not solve the problem for _all_ makes.

What if I just go ahead and install my trivial "CDPATH=" change, which
as already said, at least will do no harm and at least some good?
Then we can always decide what to do if problems persist for some non
GNU make's, say maybe clearmake.  (Maybe add `export' or maybe go for
(3).)

People with possibly problematic make's can always experiment by
making directories, say ~/cdpath and ~/cdpath/src and doing `export
CDPATH=~/cdpath" before bootstrapping or using other instances of
make.  (Of course, do not forget to set CDPATH back afterwards.)

Sincerely,

Luc.

  reply	other threads:[~2004-02-04 19:36 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-31  0:02 make bootstrap fails Steven T. Hatton
2004-01-31  0:44 ` Luc Teirlinck
2004-01-31  0:54   ` Steven T. Hatton
2004-01-31  1:32     ` make bootstrap fails. env problem Steven T. Hatton
2004-01-31  0:57   ` make bootstrap fails Steven T. Hatton
2004-01-31  1:48     ` Luc Teirlinck
2004-01-31  2:07       ` Steven T. Hatton
2004-01-31  3:20       ` Steven T. Hatton
2004-02-01 18:10         ` Richard Stallman
2004-01-31 20:02 ` Kai Grossjohann
2004-02-01 21:34   ` Kim F. Storm
2004-02-01 20:52     ` Luc Teirlinck
2004-02-01 21:40       ` Kai Grossjohann
2004-02-01 22:08         ` Luc Teirlinck
2004-02-02 23:05           ` Richard Stallman
2004-02-03 22:05             ` Luc Teirlinck
2004-02-04 10:07               ` Kim F. Storm
2004-02-04 15:21                 ` Luc Teirlinck
2004-02-04 16:55                   ` Jan D.
2004-02-04 19:36                     ` Luc Teirlinck [this message]
2004-02-04 22:51                       ` Kim F. Storm
2004-02-04 20:51                     ` Luc Teirlinck
2004-02-04 16:56                   ` Kim F. Storm
2004-02-01 22:27         ` Luc Teirlinck
2004-02-02  7:09           ` Kai Grossjohann
2004-02-02 14:28             ` Luc Teirlinck
2004-02-02 17:11               ` Stefan Monnier
2004-02-02 18:51                 ` Luc Teirlinck
2004-02-02 20:02                   ` Stefan Monnier
2004-02-02 22:59                     ` Luc Teirlinck
2004-02-02 19:01                 ` Luc Teirlinck
2004-02-01 23:46       ` Kim F. Storm
2004-02-01 23:02         ` Luc Teirlinck
     [not found] <mailman.762.1333928770.20052.help-gnu-emacs@gnu.org>
2012-04-10  2:46 ` Stefan Monnier
2012-04-10 22:54   ` Glenn Morris
2012-04-11  0:46     ` Stefan Monnier
2012-04-11  2:10       ` Glenn Morris
2012-04-11  2:57         ` Stefan Monnier
2012-04-11  3:24           ` Glenn Morris
2012-04-11 10:22             ` Chris Van Dusen
  -- strict thread matches above, loose matches on Subject: below --
2012-04-08 23:46 Chris Van Dusen
2012-04-09  3:04 ` Kuroishi Mitsuo
2012-04-09  6:52 ` Eli Zaretskii
2012-04-09 13:49   ` Chris Van Dusen
2012-04-09 15:47     ` Eli Zaretskii
2012-04-09 16:41       ` cavd
2005-10-29 16:53 Emacs-Hacker
2005-07-27 13:35 make (bootstrap) fails Lennart Borgman
2005-07-27 13:47 ` Lennart Borgman
2005-07-27 14:39   ` Juanma Barranquero
2005-07-27 14:50     ` Lennart Borgman
2005-07-27 14:48 ` Eli Zaretskii
2005-07-27 15:13   ` Juanma Barranquero
2003-02-13 23:03 make bootstrap fails Mark Moll
2003-02-14 10:03 ` Juanma Barranquero
2002-11-08 20:04 Kai Großjohann
2002-11-09 13:17 ` Henrik Enberg
2002-11-11 10:19   ` Richard Stallman
2002-11-12 18:29     ` Henrik Enberg
2002-11-14 12:15       ` Richard Stallman
2002-11-14 23:38     ` Kenichi Handa
2002-11-15 14:24       ` Stefan Monnier

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=200402041936.i14Jaru03370@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@gnu.org \
    --cc=kai@emptydomain.de \
    --cc=rms@gnu.org \
    --cc=storm@cua.dk \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.