make bootstrap fails.

make bootstrap fails.

[Steven T. Hatton]

I finally figured out that I need to checkout the cvs archive to a host with a 
public IP address (or change some, to me, unknown configuration).  Now that I 
have the source, I'm having a hard time getting it to bootstrap.  

`make' results in the following message:

Your tree does not include the compiled Lisp files.
You need to do `make bootstrap' to build Emacs.
Emacs now requires Texinfo version 4.2.
make: *** [maybe_bootstrap] Error 1

`make bootstrap' results in:

(cd src;      make  mostlyclean)
/bin/sh: line 1: cd: src: No such file or directory
make[1]: Entering directory `/download/org/gnu/emacs'
(cd src;      make -w mostlyclean)
/bin/sh: line 1: cd: src: No such file or directory
make[2]: Entering directory `/download/org/gnu/emacs'
(cd src;      make -w mostlyclean)
/bin/sh: line 1: cd: src: No such file or directory
make[3]: Entering directory `/download/org/gnu/emacs'
(cd src;      make -w mostlyclean)
/bin/sh: line 1: cd: src: No such file or directory
make[4]: Entering directory `/download/org/gnu/emacs'
(cd src;      make -w mostlyclean)
/bin/sh: line 1: cd: src: No such file or directory
make[5]: Entering directory `/download/org/gnu/emacs'
(cd src;      make -w mostlyclean)
... Ad infinitum (almost)

Suggestions?

STH

Re: make bootstrap fails.

[Luc Teirlinck]

Steven T. Hatton wrote:

   Now that I have the source, I'm having a hard time getting it to
   bootstrap.

There are instructions in emacs/INSTALL.CVS.

Basically:

cd emacs
./configure
make bootstrap
make install

(Assuming that you have Texinfo version 4.2 or later.)

Sincerely,

Luc.

Re: make bootstrap fails.

[Steven T. Hatton]

On Friday 30 January 2004 19:44, Luc Teirlinck wrote:
> Steven T. Hatton wrote:
>
>    Now that I have the source, I'm having a hard time getting it to
>    bootstrap.
>
> There are instructions in emacs/INSTALL.CVS.
>
> Basically:
>
> cd emacs
> ./configure
> make bootstrap
> make install
>
> (Assuming that you have Texinfo version 4.2 or later.)
>
> Sincerely,
>
> Luc.

I should have mentioned that I had done the `./configure' prior to the 'make 
bootstrap'.  Following the above procedure results in the failure described. 
This is a SuSE 9.0 box.  

STH

Re: make bootstrap fails. env problem

[Steven T. Hatton]

On Friday 30 January 2004 19:54, Steven T. Hatton wrote:
> On Friday 30 January 2004 19:44, Luc Teirlinck wrote:

> I should have mentioned that I had done the `./configure' prior to the
> 'make bootstrap'.  Following the above procedure results in the failure
> described. This is a SuSE 9.0 box.
>
> STH

It looks to be in my user environment, but I'm not sure what is causing the 
problem.  Under a different login I am able to build.  Perhaps it smells my 
xemacs?  Rather strange, because I removed everything from $PATH but /bin 
and /usr/bin.  There's nothing but mozilla nss and nspr libs in the 
LD_LIBRARY_PATH.  

STH

Re: make bootstrap fails.

[Steven T. Hatton]

On Friday 30 January 2004 19:44, Luc Teirlinck wrote:
> Steven T. Hatton wrote:
>
>    Now that I have the source, I'm having a hard time getting it to
>    bootstrap.
>
> There are instructions in emacs/INSTALL.CVS.
>
> Basically:
>
> cd emacs
> ./configure
> make bootstrap
> make install
>
> (Assuming that you have Texinfo version 4.2 or later.)
>
> Sincerely,
>
> Luc.

I should have mentioned that I had done the `./configure' prior to the 'make 
bootstrap'.  Following the above procedure results in the failure described. 
This is a SuSE 9.0 box.  

STH

Re: make bootstrap fails.

[Luc Teirlinck]

Steven T. Hatton wrote:

   I should have mentioned that I had done the `./configure' prior to
   the 'make bootstrap'.  Following the above procedure results in the
   failure described.  This is a SuSE 9.0 box.

I do not understand then.  If you checked out the CVS correctly, you
should have an emacs/src directory, even though the error messsages
seem to claim you do not.  Do you get an error if you just do `cd src'
instead of `make bootstrap'?

Sincerely,

Luc.

Re: make bootstrap fails.

[Steven T. Hatton]

On Friday 30 January 2004 20:48, Luc Teirlinck wrote:
> Steven T. Hatton wrote:
>
>    I should have mentioned that I had done the `./configure' prior to
>    the 'make bootstrap'.  Following the above procedure results in the
>    failure described.  This is a SuSE 9.0 box.
>
> I do not understand then.  If you checked out the CVS correctly, you
> should have an emacs/src directory, even though the error messsages
> seem to claim you do not.  Do you get an error if you just do `cd src'
> instead of `make bootstrap'?
>
> Sincerely,
>
> Luc.
>

I built as root, and it built and installed without a problem. I also built 
under a different user without a problem. I also discovered I couldn't run 
make even with a bootstrapped source tree in my normal user environment. If I 
gain insight into this, I will be sure and share.  Right now, I must move 
one.

I will add, Emacs launches much more quickly than the stale build I've been 
using. 

STH

Re: make bootstrap fails.

[Steven T. Hatton]

On Friday 30 January 2004 20:48, Luc Teirlinck wrote:
> Steven T. Hatton wrote:
>
>    I should have mentioned that I had done the `./configure' prior to
>    the 'make bootstrap'.  Following the above procedure results in the
>    failure described.  This is a SuSE 9.0 box.
>
> I do not understand then.  If you checked out the CVS correctly, you
> should have an emacs/src directory, even though the error messsages
> seem to claim you do not.  Do you get an error if you just do `cd src'
> instead of `make bootstrap'?
>
> Sincerely,
>
> Luc.

I figured it out.  I recently added a CDPATH to my .bashrc. I had the feeling 
when I did it, I would regret having done so.  unset CDPATH. Problem solved.

STH

Re: make bootstrap fails.

[Richard Stallman]

    I figured it out.  I recently added a CDPATH to my .bashrc. I had the feeling 
    when I did it, I would regret having done so.  unset CDPATH. Problem solved.

I am surprised that having a CDPATH causes a problem.  If you can
determine where in the Makefile it makes a difference, we can probably
fix it easily.

Re: make bootstrap fails.

[Kai Grossjohann]

"Steven T. Hatton" <hattons@speakeasy.net> writes:

> (cd src;      make  mostlyclean)
> /bin/sh: line 1: cd: src: No such file or directory

cd fails.  So maybe it's $CDPATH or something like this?

Kai

Re: make bootstrap fails.

[Kim F. Storm]

Kai Grossjohann <kai@emptydomain.de> writes:

> "Steven T. Hatton" <hattons@speakeasy.net> writes:
> 
> > (cd src;      make  mostlyclean)
> > /bin/sh: line 1: cd: src: No such file or directory
> 
> cd fails.  So maybe it's $CDPATH or something like this?

Maybe using cd ./src is safer ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: make bootstrap fails.

[Luc Teirlinck]

Kim Storm wrote:

   Kai Grossjohann <kai@emptydomain.de> writes:

   > "Steven T. Hatton" <hattons@speakeasy.net> writes:
   > 
   > > (cd src;      make  mostlyclean)
   > > /bin/sh: line 1: cd: src: No such file or directory
   > 
   > cd fails.  So maybe it's $CDPATH or something like this?

   Maybe using cd ./src is safer ?

Except that src is not the only problem.  There are plenty of relative
names used all over Makefile.in.  I am not an expert in Makefiles, but
would the logical thing not be to execute stuff in a subshell, and
either set CDPATH to the appropriate value or unset it?  Makefile.in
already seems to do the latter at several places, but maybe there are
some inadvertent omissions.

Sincerely,

Luc.

Re: make bootstrap fails.

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Except that src is not the only problem.  There are plenty of relative
> names used all over Makefile.in.  I am not an expert in Makefiles, but
> would the logical thing not be to execute stuff in a subshell, and
> either set CDPATH to the appropriate value or unset it?  Makefile.in
> already seems to do the latter at several places, but maybe there are
> some inadvertent omissions.

Before making big changes like this, let's check with the OP whether
this is really the problem.  Just my two cents.

Kai

Re: make bootstrap fails.

[Luc Teirlinck]

Kai Grossjohann wrote:

   Before making big changes like this, let's check with the OP whether
   this is really the problem.  Just my two cents.

I do not know whether this is the problem in the case of the OP.  It
is definitely a fact though that if CDPATH is set and does not start
with a colon, problems can develop.

I did:

export CDPATH=~/  (admittedly stupid CDPATH, but still.)
./configure --without-toolkit-scroll-bars
make bootstrap

Result:

[bash2.05b.0 ~/emacscvsdir/emacs 3 11] make bootstrap
(cd src;      make  mostlyclean)
/home/teirllm/src
make[1]: Entering directory `/home/teirllm/src'
make[1]: *** No rule to make target `mostlyclean'.  Stop.
make[1]: Leaving directory `/home/teirllm/src'
make: *** [bootstrap-clean-before] Error 2

The question of whether a change in Makefile.in is necessary is
equivalent to the question of whether the Makefile should support
values of CDPATH not starting with a colon.  (If CDPATH starts with a
colon, there should be no problem.)

Sincerely,

Luc.

Re: make bootstrap fails.

[Richard Stallman]

    I do not know whether this is the problem in the case of the OP.  It
    is definitely a fact though that if CDPATH is set and does not start
    with a colon, problems can develop.

If it is not easy to fix this problem, please don't worry about it too
much.  It would be worth a small effort, but not a large one.

Re: make bootstrap fails.

[Luc Teirlinck]

Richard Stallman wrote:

       I do not know whether this is the problem in the case of the OP.  It
       is definitely a fact though that if CDPATH is set and does not start
       with a colon, problems can develop.

   If it is not easy to fix this problem, please don't worry about it too
   much.  It would be worth a small effort, but not a large one.

I set CDPATH in my shell to ~/, a highly inappropriate value for
emacs/Makefile.in and did:

make distclean
./configure --without-toolkit-scroll-bars
make bootstrap
sudo make install

without any problems after applying the trivial patch below.

A caveat is in order though.  I am not an expert on Makefile.in.
If Makefile.in for some strange reason needs to access the user's
CDPATH, then I am suggesting something dangerous, even though it works
perfectly for me.  (I usually do not have CDPATH set.)  This seems
excessively unlikely to me.

===File ~/Makefile.in-diff==================================
*** Makefile.in.~1.284.~	Mon Feb  2 16:31:15 2004
--- Makefile.in	Tue Feb  3 10:35:22 2004
***************
*** 53,58 ****
--- 53,60 ----
  
  SHELL = /bin/sh
  
+ CDPATH=
+ 
  # If Make doesn't predefine MAKE, set it here.
  @SET_MAKE@
  
============================================================

Re: make bootstrap fails.

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> without any problems after applying the trivial patch below.

I'm not sure, but some versions of make might require that you
(somehow) export the CDPATH variable to the environment, but
I don't remember the details.  

In any case, unsetting CDPATH like this cannot do any harm!

> 
> A caveat is in order though.  I am not an expert on Makefile.in.
> If Makefile.in for some strange reason needs to access the user's
> CDPATH, 

.. then I would say that Makefile.in has a bug, so there's no reason
to consider that possibility, IMO.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: make bootstrap fails.

[Luc Teirlinck]

Kim Storm wrote:

   I'm not sure, but some versions of make might require that you
   (somehow) export the CDPATH variable to the environment, but
   I don't remember the details.  

You mean that for certain versions of make one should use
`export CDPATH=' instead of just `CDPATH='?

The `make' manual seems to say that variables exported to make from
the environment are automatically exported to sub-make's anyway and,
moreover, at first view it would seem to not make any difference
whether CDPATH is the empty string or not defined at all.

Or do some versions of make actually reinitialize environment
variables directly from the shell environment that invoked make for
sub-make's if not exported?

Anyway, it would seem like the `export' can not do any harm, even
though I do not immediately understand how it could do some good.
(But I know very little about Makefiles).

Sincerely,

Luc.

Re: make bootstrap fails.

[Jan D.]

> Or do some versions of make actually reinitialize environment
> variables directly from the shell environment that invoked make for
> sub-make's if not exported?

At least clearmake (from clearcase) does not export variables by 
default.
I don't know if there is a need to reinitialize the environment,
make variables and environment variables are just kept separate.

	Jan D.

Re: make bootstrap fails.

[Luc Teirlinck]

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.

Re: make bootstrap fails.

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> There would seem to be four possibilities:

I agree with your analysis.


> 
> 1.  CDPATH=

IMO, this is sufficient, possibly with a note in PROBLEMS that make
may fail with some non-gnu versions of make if the user has a CDPATH
which doesn't include the current directory.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: make bootstrap fails.

[Luc Teirlinck]

There is also the question of whether other make's _automatically_ unset
CDPATH.  GNU make does not.  I took a look at some other Makefiles and
it would seem that a value of CDPATH not starting with a colon would
derail _most_ Makefiles, because they use cd with relative names and
apparently do not seem to do any effort to protect themselves from
CDPATH.  Just a long shot: could not unsetting CDPATH automatically be
considered a bug in GNU make?

Sincerely,

Luc.

Re: make bootstrap fails.

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Or do some versions of make actually reinitialize environment
> variables directly from the shell environment that invoked make for
> sub-make's if not exported?

I don't know -- that's why I asked...

> 
> Anyway, it would seem like the `export' can not do any harm, even
> though I do not immediately understand how it could do some good.
> (But I know very little about Makefiles).

Unless there are version of make which doesn't understand "export".

If it works in your setup without export, I suggest we don't use it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: make bootstrap fails.

[Luc Teirlinck]

Kai Grossjohann wrote:

   Before making big changes like this, let's check with the OP whether
   this is really the problem.

Actuallly, what is strange in the case of the OP is that he got an
error message saying that src did not exist.  That is strange, because
at least the version of bash I am using (bash2.05b.0) always
_implicitly_ adds a colon at the _end_ of CDPATH by trying out the
current directory if nothing else worked.  That is, you can wind up in
the wrong src, as in the example I gave, but otherwise ./src should
be found.  Maybe CDPATH caused the OP to start bootstrapping in the
wrong "emacs" directory to begin with.

Sincerely,

Luc.

Re: make bootstrap fails.

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Actuallly, what is strange in the case of the OP is that he got an
> error message saying that src did not exist.  That is strange, because
> at least the version of bash I am using (bash2.05b.0) always
> _implicitly_ adds a colon at the _end_ of CDPATH by trying out the
> current directory if nothing else worked.

Does the OP use bash?

Kai

Re: make bootstrap fails.

[Luc Teirlinck]

Kai Grossjohann wrote:

   Luc Teirlinck <teirllm@dms.auburn.edu> writes:

   > Actuallly, what is strange in the case of the OP is that he got an
   > error message saying that src did not exist.  That is strange, because
   > at least the version of bash I am using (bash2.05b.0) always
   > _implicitly_ adds a colon at the _end_ of CDPATH by trying out the
   > current directory if nothing else worked.

   Does the OP use bash?

   Kai

I should have checked better.  When bash is invoked as sh, it indeed
does not check ./ if nothing else worked.  With CDPATH=~/src, I get
the same errors as the OP when doing make bootstrap.  The Makefile
uses /bin/sh.  (Which shell the user uses is irrelevant, because bash
does not _really_ add a colon to the end of CDPATH.  It just gets the
same behavior by checking the current directory if nothing else worked.)

Sincerely,

Luc.

Re: make bootstrap fails.

[Stefan Monnier]

> I should have checked better.  When bash is invoked as sh, it indeed
> does not check ./ if nothing else worked.  With CDPATH=~/src, I get
> the same errors as the OP when doing make bootstrap.  The Makefile
> uses /bin/sh.

The SUSv3 does not list CDPATH as a variable that might affect the behavior
of /bin/sh, so I think it should be considered as a bug in bash (we'll
still need to work around it, but it should be reported to the bash
maintainers and/or to the distributions that use bash as /bin/sh).

Of course, someone should check that bash invoked as /bin/sh indeed
mistakenly obeys an inherited CDPATH envvar, but the reports here lead me
to believe this is the case.


        Stefan

Re: make bootstrap fails.

[Luc Teirlinck]

Stefan Monnier wrote:

   The SUSv3 does not list CDPATH as a variable that might affect the behavior
   of /bin/sh, so I think it should be considered as a bug in bash (we'll
   still need to work around it, but it should be reported to the bash
   maintainers and/or to the distributions that use bash as /bin/sh).

   Of course, someone should check that bash invoked as /bin/sh indeed
   mistakenly obeys an inherited CDPATH envvar, but the reports here lead me
   to believe this is the case.

I could give actual examples of bash invoked as sh obeying an
inherited CDPATH, but let me first make sure that I understand you.
Are you saying that sh should completely ignore CDPATH?  That would be
strange, because, for instance, the Solaris 8 version of sh treats
CDPATH exactly like Bash invoked as sh does, and `(bash)Bourne Shell
Variables' explicitly lists CDPATH as a variable taken over from the
Bourne shell.  Moreover, other Makefiles, for instance the texinfo-4.6
Makefile use their own CDPATH (they do not just unset CDPATH) even
though they use /bin/sh.

Sincerely,

Luc.

Re: make bootstrap fails.

[Stefan Monnier]

> I could give actual examples of bash invoked as sh obeying an
> inherited CDPATH, but let me first make sure that I understand you.
> Are you saying that sh should completely ignore CDPATH?  That would be

Well, after further reading, CDPATH is not mentioned in `sh' but is
mentioned in `cd'.  So, I guess I was wrong, and to be protected from
CDPATH, we should always use ./foo rather than foo.

Too bad: CDPATH really feels like an interactive-only feature.


        Stefan

Re: make bootstrap fails.

[Luc Teirlinck]

Stefan Monnier wrote:

   So, I guess I was wrong, and to be protected from
   CDPATH, we should always use ./foo rather than foo.

   Too bad: CDPATH really feels like an interactive-only feature.

What is wrong with just unsetting CDPATH?  As the Makefile runs in a
subshell, it will not mess up the user's environment.

Sincerely,

Luc.

Re: make bootstrap fails.

[Luc Teirlinck]

>From my earlier reply:
   
   Moreover, other Makefiles, for instance the texinfo-4.6
   Makefile use their own CDPATH (they do not just unset CDPATH) even
   though they use /bin/sh.

I said something inaccurate here: it locally sets CDPATH for one
particular command (am_cd).  But the point remains the same.  That
command is executed by /bin/sh.

Sincerely,

Luc.

Re: make bootstrap fails.

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kim Storm wrote:
> 
>    Kai Grossjohann <kai@emptydomain.de> writes:
> 
>    > "Steven T. Hatton" <hattons@speakeasy.net> writes:
>    > 
>    > > (cd src;      make  mostlyclean)
>    > > /bin/sh: line 1: cd: src: No such file or directory
>    > 
>    > cd fails.  So maybe it's $CDPATH or something like this?
> 
>    Maybe using cd ./src is safer ?
> 
> Except that src is not the only problem.  There are plenty of relative
> names used all over Makefile.in.  I am not an expert in Makefiles, but
> would the logical thing not be to execute stuff in a subshell, and
> either set CDPATH to the appropriate value or unset it?  Makefile.in
> already seems to do the latter at several places, but maybe there are
> some inadvertent omissions.

Things are executed in a subshell, so I guess the Makefile should
be able to unset CDPATH in the environment at the global level.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: make bootstrap fails.

[Luc Teirlinck]

Kim Storm wrote:

   Things are executed in a subshell, so I guess the Makefile should
   be able to unset CDPATH in the environment at the global level.

Yes, unless the Makefile would for some strange reason need to use the
user defined value of CDPATH, at one place or another, which seems
excessively unlikely.

Sincerely,

Luc.