INSTALL-CVS

INSTALL-CVS

[D. Goel]

It seems that the discussion on INSTALL-CVS has died down.   Here's
the latest INSTALL-CVS, if maintainers would like to install it--->




	      Building and Installing Emacs from the CVS

The Emacs tarball contains byte-compiled versions of the Lisp files.
The CVS repository does not contain the byte-compiled files.
Therefore, to build from CVS you must run `make bootstrap'
instead of just `make':

  $ ./configure
  $ make bootstrap


Normally, it is not necessary to use "make bootstrap" after every CVS
update.  Unless there are problems, "make all" should be used.

Re: INSTALL-CVS

[Simon Josefsson]

"D. Goel" <deego@glue.umd.edu> writes:

> It seems that the discussion on INSTALL-CVS has died down.   Here's
> the latest INSTALL-CVS, if maintainers would like to install it--->
>
>
>
>
> 	      Building and Installing Emacs from the CVS
>
> The Emacs tarball contains byte-compiled versions of the Lisp files.
> The CVS repository does not contain the byte-compiled files.
> Therefore, to build from CVS you must run `make bootstrap'
> instead of just `make':
>
>   $ ./configure
>   $ make bootstrap
>
>
> Normally, it is not necessary to use "make bootstrap" after every CVS
> update.  Unless there are problems, "make all" should be used.

What about "make recompile" in lisp/?  I find myself often doing that
instead of bootstrap, once I've run bootstrap once.

Re: INSTALL-CVS

[Eli Zaretskii]

On Sun, 16 Jun 2002, Simon Josefsson wrote:

> >   $ ./configure
> >   $ make bootstrap
> >
> >
> > Normally, it is not necessary to use "make bootstrap" after every CVS
> > update.  Unless there are problems, "make all" should be used.
> 
> What about "make recompile" in lisp/?

I added that and installed the file.

Thanks.

Re: INSTALL-CVS

[D. Goel]

> > > Normally, it is not necessary to use "make bootstrap" after every CVS
> > > update.  Unless there are problems, "make all" should be used.
> > 
> > What about "make recompile" in lisp/?



And just a reminder to all that if your suggestions did not make it
into the official INSTALL-CVS, please put them up on the wiki at:
http://www.emacswiki.org/cgi-bin/wiki.pl?EmacsFromCVS

Your stuff here, will be further improved by people visting the site,
and the best of the best here could then perhaps make it into the
official versions..


DG				   
-- 

Re: INSTALL-CVS

[Eli Zaretskii]

On 18 Jun 2002, D. Goel wrote:

> And just a reminder to all that if your suggestions did not make it
> into the official INSTALL-CVS, please put them up on the wiki at:
> http://www.emacswiki.org/cgi-bin/wiki.pl?EmacsFromCVS

Please check out the version of INSTALL-CVS in the CVS.  I think I 
incorporated all the relevant suggestions people posted here during the 
discussions.

INSTALL-CVS

[Nick Roberts]

In the file, INSTALL-CVS, it says:

> Normally, it is not necessary to use "make bootstrap" after every CVS
> update.  Unless there are problems, we suggest the following
> procedure:
> 
>   $ ./configure
>   $ make
>   $ cd lisp
>   $ make recompile EMACS=../src/emacs
>   $ cd ..
>   $ make

The user presumably also wants up-to-date documentation so shouldn't
it also have?:

  $ cd man
  $ make info

Would it be a good idea to have one target to do all these things,
`make cvs', say?

Nick

Re: INSTALL-CVS

[Eli Zaretskii]

> From: Nick Roberts <nick@nick.uklinux.net>
> Date: Thu, 29 May 2003 22:31:36 +0100
> 
> > Normally, it is not necessary to use "make bootstrap" after every CVS
> > update.  Unless there are problems, we suggest the following
> > procedure:
> > 
> >   $ ./configure
> >   $ make
> >   $ cd lisp
> >   $ make recompile EMACS=../src/emacs
> >   $ cd ..
> >   $ make
> 
> The user presumably also wants up-to-date documentation so shouldn't
> it also have?:
> 
>   $ cd man
>   $ make info

??? Are you saying that on your machine, if you type "make" in the
top-level directory, it doesn't recurse into the `man' subdirectory
automatically?

Re: INSTALL-CVS

[Nick Roberts]

 > ??? Are you saying that on your machine, if you type "make" in the
 > top-level directory, it doesn't recurse into the `man' subdirectory
 > automatically?

Yes, I think thats right. 

My Makefile has these two lines

all: ${SUBDIR} leim

SUBDIR = lib-src src

So only these three directories in the top-level are visited.

Nick

Re: INSTALL-CVS

[Eli Zaretskii]

> From: Nick Roberts <nick@nick.uklinux.net>
> Date: Sun, 1 Jun 2003 21:51:40 +0100
> 
>  > ??? Are you saying that on your machine, if you type "make" in the
>  > top-level directory, it doesn't recurse into the `man' subdirectory
>  > automatically?
> 
> Yes, I think thats right. 
> 
> My Makefile has these two lines
> 
> all: ${SUBDIR} leim
> 
> SUBDIR = lib-src src
> 
> So only these three directories in the top-level are visited.

That's because in the normal (non-CVS) build, the files in the info
directory are already there.

Sorry, I forgot all those gory details.  The _real_ answer to your
question is that (1) "make bootstrap" builds the Info manuals,
and (2) if you build the CVS without bootstrapping, "make instal"
will make sure the Info manuals are up to date, and if not rebuild
them (see the target install-arch-indep which depends on info).

Given that, do you still think we should tell users to invoke Make in
the man subdirectory, and if so, why?

Re: INSTALL-CVS

[Stefan Monnier]

> That's because in the normal (non-CVS) build, the files in the info
> directory are already there.
> 
> Sorry, I forgot all those gory details.  The _real_ answer to your
> question is that (1) "make bootstrap" builds the Info manuals,
> and (2) if you build the CVS without bootstrapping, "make instal"
> will make sure the Info manuals are up to date, and if not rebuild
> them (see the target install-arch-indep which depends on info).

I have changed my Makefile.in long ago to add `man' to the default
target.  The only cases where it might hurt is if the Emacs tarball
comes with Texinfo files more recent than the Info files (that would
be a bug in the tarball) or if the program that untars the tarball
does not obey the timestamps in the tarball and happens to untar
the Texinfo files after untarring the Ifno files.

Maybe we can avoid all this by using two different Makefile.in
depending on whether it's checked out via CVS or taken from a tarball.
I.e. the `make-dist' script would slightly adjust the Makefile.in by
removing the `man' target from the default target.


	Stefan

Re: INSTALL-CVS

[Nick Roberts]

 > I have changed my Makefile.in long ago to add `man' to the default
 > target.  The only cases where it might hurt is if the Emacs tarball
 > comes with Texinfo files more recent than the Info files (that would
 > be a bug in the tarball) or if the program that untars the tarball
 > does not obey the timestamps in the tarball and happens to untar
 > the Texinfo files after untarring the Ifno files.
 > 
 > Maybe we can avoid all this by using two different Makefile.in
 > depending on whether it's checked out via CVS or taken from a tarball.
 > I.e. the `make-dist' script would slightly adjust the Makefile.in by
 > removing the `man' target from the default target.

Assuming that the advice in INSTALL-CVS is sound, why would the target below,
added to the Makefile (or rather Makefile.in) in the top directory, not work?

cvs:
	$(MAKE)
	(cd lisp; $(MAKE) recompile EMACS=../src/emacs)
	$(MAKE)
	(cd man; $(MAKE))

then INSTALL-CVS could advise:

 $ ./configure
 $ make cvs

after an update.


Nick

Re: INSTALL-CVS

[Nick Roberts]

 > Sorry, I forgot all those gory details.  The _real_ answer to your
 > question is that (1) "make bootstrap" builds the Info manuals,
 > and (2) if you build the CVS without bootstrapping, "make instal"
 > will make sure the Info manuals are up to date, and if not rebuild
 > them (see the target install-arch-indep which depends on info).
 > 
 > Given that, do you still think we should tell users to invoke Make in
 > the man subdirectory, and if so, why?

make bootstrap takes a very long time on my machine. I don't want to use make
install as I use everything where it was built (my CVS copy crashes far too
often to put it anywhere permanent ;-)). I do want up-to-date documentation,
however, as that is one source of information for the current build. I would
guess there are others who think likewise.

Nick

Re: INSTALL-CVS

[Richard Stallman]

     > ??? Are you saying that on your machine, if you type "make" in the
     > top-level directory, it doesn't recurse into the `man' subdirectory
     > automatically?

    Yes, I think thats right. 

I believe this was deliberate.  I think the reason was that we don't
want `make' to recurse into `man' and generate a DVI file, and we
normally distribute Emacs with the Info files already updated, so
there is no need for it to update them.

However, I guess it would be harmless now to change it so that
top-level `make all' updates the Info files but does not generate the
DVI files.

Re: INSTALL-CVS

[David Masterson]

>>>>> Richard Stallman writes:

> However, I guess it would be harmless now to change it so that
> top-level `make all' updates the Info files but does not generate
> the DVI files.

Suggestion -- have the configure script 'touch' the Info files as the
last thing it does if and only if they exist at the time of the
'configure'.  Then 'make all' shouldn't update the Info files that are
delivered with the distribution, but should do the right thing at all
other times without requiring any special tricks in the Makefiles.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: INSTALL-CVS

[Andreas Schwab]

David Masterson <David.Masterson@synopsys.com> writes:

|> >>>>> Richard Stallman writes:
|> 
|> > However, I guess it would be harmless now to change it so that
|> > top-level `make all' updates the Info files but does not generate
|> > the DVI files.
|> 
|> Suggestion -- have the configure script 'touch' the Info files as the
|> last thing it does if and only if they exist at the time of the
|> 'configure'.

This is counter-productive, because then if you rerun configure when the
info files are out-of-date they won't be rebuilt.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: INSTALL-CVS

[Stefan Monnier]

> David Masterson <David.Masterson@synopsys.com> writes:
> 
> |> >>>>> Richard Stallman writes:
> |> 
> |> > However, I guess it would be harmless now to change it so that
> |> > top-level `make all' updates the Info files but does not generate
> |> > the DVI files.
> |> 
> |> Suggestion -- have the configure script 'touch' the Info files as the
> |> last thing it does if and only if they exist at the time of the
> |> 'configure'.
> 
> This is counter-productive, because then if you rerun configure when the
> info files are out-of-date they won't be rebuilt.

Agreed.

I think we should simply add `man' to the default target and
live with it.  If that means that `makeinfo' is sometimes called
when a user installs Emacs, what's the big deal ?
If the problem is that the user might not have a working `makeinfo',
how about running it with a leading "-" so that an error from
`makeinfo' is ignored by make ?


	Stefan

Re: INSTALL-CVS

[David Masterson]

>>>>> Stefan Monnier writes:

>> David Masterson <David.Masterson@synopsys.com> writes:
>> 
>> |> >>>>> Richard Stallman writes:
>> |> 
>> |> > However, I guess it would be harmless now to change it so that
>> |> > top-level `make all' updates the Info files but does not generate
>> |> > the DVI files.
>> |> 
>> |> Suggestion -- have the configure script 'touch' the Info files as the
>> |> last thing it does if and only if they exist at the time of the
>> |> 'configure'.
>> 
>> This is counter-productive, because then if you rerun configure when the
>> info files are out-of-date they won't be rebuilt.

Is there a configure output file that could be checked for existence
(config.log) and don't do the 'touch' in  that case?

> Agreed.

> I think we should simply add `man' to the default target and live
> with it.  If that means that `makeinfo' is sometimes called when a
> user installs Emacs, what's the big deal ?  If the problem is that
> the user might not have a working `makeinfo', how about running it
> with a leading "-" so that an error from `makeinfo' is ignored by
> make ?

Ignoring the error in 'man' would cause 'install-man' to fail.
Perhaps configure should test for a working 'makeinfo' (if it doesn't
already) and default to (say) '/bin/true' if no working makeinfo is
found?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: INSTALL-CVS

[Stefan Monnier]

> > I think we should simply add `man' to the default target and live
> > with it.  If that means that `makeinfo' is sometimes called when a
> > user installs Emacs, what's the big deal ?  If the problem is that
> > the user might not have a working `makeinfo', how about running it
> > with a leading "-" so that an error from `makeinfo' is ignored by
> > make ?
> 
> Ignoring the error in 'man' would cause 'install-man' to fail.

Why would it ?


	Stefan

Re: INSTALL-CVS

[David Masterson]

>>>>> Stefan Monnier writes:

>> > I think we should simply add `man' to the default target and live
>> > with it.  If that means that `makeinfo' is sometimes called when a
>> > user installs Emacs, what's the big deal ?  If the problem is that
>> > the user might not have a working `makeinfo', how about running it
>> > with a leading "-" so that an error from `makeinfo' is ignored by
>> > make ?
>> 
>> Ignoring the error in 'man' would cause 'install-man' to fail.

> Why would it ?

Hmmm.  Am I missing something obvious?  Because the 'man' target fails
in generating the Info files (assume none previously existed) with
makeinfo, but the error is ignored, so the build would go on to the
'install-man' target which would try to copy the Info files to where
they should be installed and, thus, fail.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: INSTALL-CVS

[Stefan Monnier]

> >> > I think we should simply add `man' to the default target and live
> >> > with it.  If that means that `makeinfo' is sometimes called when a
> >> > user installs Emacs, what's the big deal ?  If the problem is that
> >> > the user might not have a working `makeinfo', how about running it
> >> > with a leading "-" so that an error from `makeinfo' is ignored by
> >> > make ?
> >> 
> >> Ignoring the error in 'man' would cause 'install-man' to fail.
> 
> > Why would it ?
> 
> Hmmm.  Am I missing something obvious?  Because the 'man' target fails

If the info files aren't there and the makeinfo fails, there's
not much we can do and it's not an interesting case.  The case we need
to pay attention to is the one where the user untars the tarball,
the timestamps get messed up and the make unnecessarily runs
makeinfo even though the info files are already there (and are
uptodate, since if they're not uptodate that means the tarball
is buggy anyway).


	Stefan

Re: INSTALL-CVS

[Richard Stallman]

    I think we should simply add `man' to the default target and
    live with it.  If that means that `makeinfo' is sometimes called
    when a user installs Emacs, what's the big deal ?

Why would it have that effect?  The info files in a release
should always be up to date.

Re: INSTALL-CVS

[Stefan Monnier]

>     I think we should simply add `man' to the default target and
>     live with it.  If that means that `makeinfo' is sometimes called
>     when a user installs Emacs, what's the big deal ?
> 
> Why would it have that effect?  The info files in a release
> should always be up to date.

Agreed.  I thought the reason why `man' was not in the default
target was because some `tar's might leave timestamps alone,
so that the relative timestamps depend on the order in which
the files were extracted from the tarball.

Any objection to the patch below ?


	Stefan


--- Makefile.in 23 Feb 2003 17:07:42 -0000      1.280
+++ Makefile.in 5 Jun 2003 14:01:42 -0000
@@ -239,7 +239,7 @@
 # Set to FRC to force running autoconf and autoheader
 MAINT =
 
-all: ${SUBDIR} leim
+all: ${SUBDIR} leim info
 
 removenullpaths=sed -e 's/^://g' -e 's/:$$//g' -e 's/::/:/g'

Re: INSTALL-CVS

[Nick Roberts]

 > Agreed.  I thought the reason why `man' was not in the default
 > target was because some `tar's might leave timestamps alone,
 > so that the relative timestamps depend on the order in which
 > the files were extracted from the tarball.
 > 
 > Any objection to the patch below ?
 > ...

Or, in case there is a problem for the tarball, how about:


all: ${SUBDIR} leim cvs

cvs:
	if [ -f INSTALL-CVS ]; \
	then $(MAKE) info; \
	fi

as I assume the file, INSTALL-CVS, isn't included in the tarball and
the user need only type make in both cases.

Nick

Re: INSTALL-CVS

[Richard Stallman]

    Agreed.  I thought the reason why `man' was not in the default
    target was because some `tar's might leave timestamps alone,
    so that the relative timestamps depend on the order in which
    the files were extracted from the tarball.

Does anyone know if this is true?
If it is true, and Make tries to run makeinfo on a system
that doesn't have it, that will get an error
but the info files will still be correct
(as they were in the distro).  So what we want is
to ignore errors from the recursive make for the man dir.

Re: INSTALL-CVS

[David Masterson]

>>>>> Andreas Schwab writes:

> David Masterson <David.Masterson@synopsys.com> writes:
> |> >>>>> Richard Stallman writes:
> |> 
> |> > However, I guess it would be harmless now to change it so that
> |> > top-level `make all' updates the Info files but does not
> |> > generate the DVI files.
> |> 
> |> Suggestion -- have the configure script 'touch' the Info files as
> |> the last thing it does if and only if they exist at the time of
> |> the 'configure'.

> This is counter-productive, because then if you rerun configure when
> the info files are out-of-date they won't be rebuilt.

I think I understand what you're saying, but I'm not sure why anyone
would *rerun* configure in a "built" environment and not do something
like 'make clean' first.

Perhaps the 'touch' could be done only on first run of configure?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: INSTALL-CVS

[Stefan Monnier]

> I think I understand what you're saying, but I'm not sure why anyone
> would *rerun* configure in a "built" environment and not do something
> like 'make clean' first.

I never understand why anyone would do `make clean' (probably
because I can never remember which of `clean', `extraclean', `distclean',
`fooclean', `hyperclean', or `megaclean' does what I want).

./configure is rerun for me whenever `configure' changes.


	Stefan

Re: INSTALL-CVS

[David Masterson]

>>>>> Stefan Monnier writes:

>> I think I understand what you're saying, but I'm not sure why
>> anyone would *rerun* configure in a "built" environment and not do
>> something like 'make clean' first.

> I never understand why anyone would do `make clean' (probably
> because I can never remember which of `clean', `extraclean',
> `distclean', `fooclean', `hyperclean', or `megaclean' does what I
> want).

> ./configure is rerun for me whenever `configure' changes.

Hmmm.  But, since most (all?) 'make' commands only do time-stamp
checking to determine if a target should be rebuilt, if the rerun of
configure causes the Makefile(s) to be regen'ed with new or changed
commands in a target, that target may not be rebuilt because you
didn't "clean" your environment first.  True?

When you're familiar with the environment (as you are with Emacs), you
can get away without cleaning your environment first.  However, the
safe approach is to only 'configure' in a clean environment.

CPU cycles are relatively cheap nowadays...  ;-)

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: INSTALL-CVS

[Stefan Monnier]

> When you're familiar with the environment (as you are with Emacs), you
> can get away without cleaning your environment first.  However, the
> safe approach is to only 'configure' in a clean environment.

It seems the only time that I need to re-run a configure script
is when I'm hacking on the corresponding program.  Otherwise,
I just untar, configure, make install, and throw away.


	Stefan

Re: INSTALL-CVS

[David Masterson]

>>>>> Stefan Monnier writes:

>> When you're familiar with the environment (as you are with Emacs), you
>> can get away without cleaning your environment first.  However, the
>> safe approach is to only 'configure' in a clean environment.

> It seems the only time that I need to re-run a configure script
> is when I'm hacking on the corresponding program.  Otherwise,
> I just untar, configure, make install, and throw away.

Thus my original suggestion to 'touch' the Info files at the end of
configure (iff they exist) is not so counter-productive after all.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: INSTALL-CVS

[Richard Stallman]

    It seems the only time that I need to re-run a configure script
    is when I'm hacking on the corresponding program.  Otherwise,
    I just untar, configure, make install, and throw away.

Perhaps disks are big enough nowadays that people don't need
to delete their tar files.  Maybe that means `make clean' is
less needed than it was 15 years ago.

Re: INSTALL-CVS

[David Masterson]

>>>>> Richard Stallman writes:

> Perhaps disks are big enough nowadays that people don't need
> to delete their tar files.  Maybe that means `make clean' is
> less needed than it was 15 years ago.

Well, deleting a tar file is not often a big deal as it's probably on
a backup tape or in a snapshot directory or can easily be downloaded
again.  Because 'make' is timestamp based, 'make clean' is *sometimes*
necessary to get something rebuilt properly if you hack the Makefile
(which is what a re-configure potentially does).  The level of
'clean'ness needed is dependent upon how radically the Makefile is
hacked.  It's also sometimes needed because a source file is changed
(as in 'cvs update'), but a target in the Makefile that depends on the
source file doesn't explicitly state the dependency (usually a bug in
the Makefile, but sometimes purposely done).

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: INSTALL-CVS

[Andreas Schwab]

David Masterson <David.Masterson@synopsys.COM> writes:

|> Hmmm.  But, since most (all?) 'make' commands only do time-stamp
|> checking to determine if a target should be rebuilt, if the rerun of
|> configure causes the Makefile(s) to be regen'ed with new or changed
|> commands in a target, that target may not be rebuilt because you
|> didn't "clean" your environment first.  True?

Yes, but it almost never matters.

|> When you're familiar with the environment (as you are with Emacs), you
|> can get away without cleaning your environment first.  However, the
|> safe approach is to only 'configure' in a clean environment.

It has been a long time since I last did a make clean.

|> CPU cycles are relatively cheap nowadays...  ;-)

Why should I waste CPU cycles when I can do more important things with
them?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."