Re: NT Emacs make problem..

Re: NT Emacs make problem..

[Richard Stallman]

    > BTW, In general, is there a "README" or "INSTALL" regarding emacs
    > checked out from savannah, where do i find it?

    There is no such thing yet.

This is a serious gap; we are asking for trouble (as well as wasting
the time of people who want to help us) if we don't provide this
information.

Perhaps the INSTALL file that we put in the tarball should have a
different name in CVS, perhaps TARBALL-INSTALL, and the INSTALL file
in CVS could give instructions for building from CVS.  make-dist could
then do mv TARBALL-INSTALL INSTALL.  It could also do mv INSTALL
CVS-INSTALL first, so as not to lose that file entirely, if that is
useful.

Is it enough to tell people to do `make bootstrap' after running
./configure?  What else do people need to know?

Re: NT Emacs make problem..

[Thien-Thi Nguyen]

Richard Stallman <rms@gnu.org> writes:

   Is it enough to tell people to do `make bootstrap' after running
   ./configure?  What else do people need to know?

CVSREAD=1 causes problems.

thi

Re: NT Emacs make problem..

[Eli Zaretskii]

> Date: Thu, 6 Jun 2002 18:44:42 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
> Perhaps the INSTALL file that we put in the tarball should have a
> different name in CVS, perhaps TARBALL-INSTALL, and the INSTALL file
> in CVS could give instructions for building from CVS.

I suggest to have a separate file, called INSTALL-CVS or something.
We could omit it from the tarball if we want to avoid confusing
people.

Re: NT Emacs make problem..

[D. Goel]

here's a little draft for INSTALL-CVS :-) 


====================================================
 -*-text-*- 
		      Building and Installing Emacs
			 from the CVS

  Copyright (c) 2001 Free Software Foundation, Inc.
  See the end of the file for copying permissions.

The build-instructions for a release and CVS are slightly different. 

The tarball in an Emacs release usually contains byte-compiled code
for some of the files.  However, for the files checked out from CVS,
there are no byte-compiled files. 

To build emacs from a CVS checkout, follow the instructions as you
would for the tarball, except that replace the initial 'make' by 'make
bootstrap'.



COPYING PERMISSIONS

  Permission is granted to anyone to make or distribute verbatim copies
  of this document as received, in any medium, provided that the
  copyright notice and permission notice are preserved,
  and that the distributor grants the recipient permission
  for further redistribution as permitted by this notice.

  Permission is granted to distribute modified versions
  of this document, or of portions of it,
  under the above conditions, provided also that they
  carry prominent notices stating who last changed them,
  and that any new or changed statements about the activities
  of the Free Software Foundation are approved by the Foundation

Re: NT Emacs make problem..

[Simon Josefsson]

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

> here's a little draft for INSTALL-CVS :-) 

Looks good, except that IMHO commands should be easier to locate
visually, not embedded in the text, because people don't like to read
text and the only reason for reading the file is to find out the
command to run, not to read the text.

Suggested change below:

>
>
> ====================================================
>  -*-text-*- 
> 		      Building and Installing Emacs
> 			 from the CVS
>
>   Copyright (c) 2001 Free Software Foundation, Inc.
>   See the end of the file for copying permissions.
>
> The build-instructions for a release and CVS are slightly different. 
>
> The tarball in an Emacs release usually contains byte-compiled code
> for some of the files.  However, for the files checked out from CVS,
> there are no byte-compiled files. 
>
> To build emacs from a CVS checkout, follow the instructions as you
> would for the tarball, except that replace the initial 'make' by 'make
 bootstrap', e.g.:

  $ ./configure
  $ make bootstrap
>
>
>
> COPYING PERMISSIONS
>
>   Permission is granted to anyone to make or distribute verbatim copies
>   of this document as received, in any medium, provided that the
>   copyright notice and permission notice are preserved,
>   and that the distributor grants the recipient permission
>   for further redistribution as permitted by this notice.
>
>   Permission is granted to distribute modified versions
>   of this document, or of portions of it,
>   under the above conditions, provided also that they
>   carry prominent notices stating who last changed them,
>   and that any new or changed statements about the activities
>   of the Free Software Foundation are approved by the Foundation

Re: NT Emacs make problem..

[D. Goel]

Simon Josefsson <jas@extundo.com> writes:
> 
> Suggested change below:

[...]

> 
>   $ ./configure
>   $ make bootstrap


Thanks, nice suggestion.. i made this change to that file.  


[...]


Have a good day,

DG				   <http://www.glue.umd.edu/~deego/>
-- 

Re: NT Emacs make problem..

[Richard Stallman]

    > Perhaps the INSTALL file that we put in the tarball should have a
    > different name in CVS, perhaps TARBALL-INSTALL, and the INSTALL file
    > in CVS could give instructions for building from CVS.

    I suggest to have a separate file, called INSTALL-CVS or something.

I guess that name would be evident enough.  Can you write down
the necessary directions?

    The tarball in an Emacs release usually contains byte-compiled code
    for some of the files.

(Actually, for all the Lisp files that should be compiled.)

			    However, for the files checked out from CVS,
    there are no byte-compiled files. 

    To build emacs from a CVS checkout, follow the instructions as you
    would for the tarball, except that replace the initial 'make' by 'make
    bootstrap'.

Is this really complete?  That is the real question.
What else do people need to know?

Re: NT Emacs make problem..

[Richard Stallman]

       Is it enough to tell people to do `make bootstrap' after running
       ./configure?  What else do people need to know?

    CVSREAD=1 causes problems.

Do you mean that doing the checkout with CVSREAD=1 leads to bad source
files?

Re: NT Emacs make problem..

[Thien-Thi Nguyen]

   From: Richard Stallman <rms@gnu.org>
   Date: Sat, 8 Jun 2002 13:15:53 -0600 (MDT)

   Do you mean that doing the checkout with CVSREAD=1 leads to bad source
   files?

sorry i wasn't more precise: CVSREAD=1 causes "cvs checkout" to create
read-only files.  some steps in "make bootstrap" fail because they need
to recreate or update files, and cannot do so.  (source files are not
corrupted, in any case.)

there was discussion previously about some script to be run immediately
after a "cvs checkout" but before "make bootstrap".  i suggest we write
that script, include "chmod +w $cannot_be_ro_file_list", and publish the
way to build emacs from cvs as:

 cvs checkout ...
 cd emacs
 sh -x prep-bootstrap	# ("-x" for entertainment purposes :-)
 make bootstrap

prep-bootstrap need not be distributed.

thi

Re: NT Emacs make problem..

[D. Goel]

>     > Perhaps the INSTALL file that we put in the tarball should have a
>     > different name in CVS, perhaps TARBALL-INSTALL, and the INSTALL file
>     > in CVS could give instructions for building from CVS.
> 
>     I suggest to have a separate file, called INSTALL-CVS or something.
> 
> I guess that name would be evident enough.  Can you write down
> the necessary directions?


Sure, i shall write down all the 'directions' that emerge from this
thread into that INSTALL-CVS i posted, and finally post the completed
INSTALL-CVS to the list..



DG				   <http://www.glue.umd.edu/~deego/>
-- 

Re: NT Emacs make problem..

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> What else do people need to know [to build Emacs from CVS]?

I always run autoconf, then configure, then make bootstrap.  This
means that sometimes I get CVS conflicts in lisp/cus-load.el,
lisp/loaddefs.el and, occasionally, the configure script.  "cvs
update -C" is my friend.

Other people seem to run make bootstrap as seldom as possible,
preferring regular make all after the first make bootstrap.

And then, people might be interested in a fast method that does as
little as possible after a CVS update.  I think that it is possible
to be even faster than "make all"?

Those are the things that could be mentioned in the INSTALL-CVS
file.  Opinions?

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: NT Emacs make problem..

[Kim F. Storm]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > What else do people need to know [to build Emacs from CVS]?
>

I work on other project where I need to use CVSREAD=y

This means that I have to checkout (not update)

        cvs co ...
        chmod -R u+w .
        ./configure
        make bootstrap

However, if you build in a different directory (the details are in INSTALL),
you can avoid "polluting" the checked out sources with the build.

> And then, people might be interested in a fast method that does as
> little as possible after a CVS update.  I think that it is possible
> to be even faster than "make all"?

I typically use the following to update and compile:

        cvs up
        (cd lisp; make recompile)
        make

PS:  I suggested to create an INTRO_CVS file a while back which should
contain just this kind of information; maybe you can grep through the
emacs-devel archives to see what was suggested back then.

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

Re: NT Emacs make problem..

[Richard Stallman]

    Sure, i shall write down all the 'directions' that emerge from this
    thread into that INSTALL-CVS i posted, and finally post the completed
    INSTALL-CVS to the list..

Please do.  However, if it is as simple as it seems to be, we need not
fuss with a license notice.  They are not needed on very small files.

We may not need any more directions; aside from the CVSREAD issue
which we might solve in a different way, nobody has mentioned
any other requirements.

Re: NT Emacs make problem..

[Richard Stallman]

      i suggest we write
    that script, include "chmod +w $cannot_be_ro_file_list", and publish the
    way to build emacs from cvs as:

     cvs checkout ...
     cd emacs
     sh -x prep-bootstrap	# ("-x" for entertainment purposes :-)
     make bootstrap

Why not put those preparations into the `bootstrap' target in Makefile?
That target is meant for use on a CVS checkout, and these chmods
do no harm there.  Would you like to write the appropriate command
and add it to Makefile.in?

Re: NT Emacs make problem..

[Thien-Thi Nguyen]

Richard Stallman <rms@gnu.org> writes:

   Why not put those preparations into the `bootstrap' target in Makefile?
   That target is meant for use on a CVS checkout, and these chmods
   do no harm there.  Would you like to write the appropriate command
   and add it to Makefile.in?

not really.  i get particular on build methodology and am likely to whine
about other things (unproductively) if i get involved in this way.  perhaps
D. Goel can supply the appropriate patch in addition to writing INSTALL-CVS.

thi

Re: NT Emacs make problem..

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> We may not need any more directions; aside from the CVSREAD issue
> which we might solve in a different way, nobody has mentioned
> any other requirements.

What about mentioning different ways to build Emacs?  (One could
always use "make bootstrap", then there might be CVS conflicts which
need to be mentioned.  Or one could try to abstain from "make
bootstrap" as often as possible, then there should be a hint on when
"make bootstrap" is necessary.  There could also be some text
explaining pros/cons of the approaches.)  Even if only one of the
alternatives is explained, there should be some explanatory text,
IMVHO.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: NT Emacs make problem..

[Richard Stallman]

    I always run autoconf, then configure, then make bootstrap.  This
    means that sometimes I get CVS conflicts in lisp/cus-load.el,
    lisp/loaddefs.el and, occasionally, the configure script.  "cvs
    update -C" is my friend.

Since you know how to cope with running Autoconf yourself, it is
useful that you test it.  However, I think we should not recommend the
running of Autoconf as part of the usual way to build Emacs from the
CVS version.

Re: NT Emacs make problem..

[D. Goel]

>     Sure, i shall write down all the 'directions' that emerge from this
>     thread into that INSTALL-CVS i posted, and finally post the completed
>     INSTALL-CVS to the list..
> 
> Please do.  However, if it is as simple as it seems to be, we need not
> fuss with a license notice.  They are not needed on very small files.

'COPYING NOTICE' removed.

> 
> We may not need any more directions

Cool, we are done with this file then :).  I am including the file at
the end of this mail.  perhaps, Could the maintainers please install it?


Have a good day,

DG				   <http://www.glue.umd.edu/~deego/>
-- 
====================================================

		      Building and Installing Emacs
		      		 from the CVS

  Copyright (c) 2001 Free Software Foundation, Inc.

The build-instructions for a release and CVS are slightly different. 

The tarball in an Emacs release usually contains byte-compiled code
for some of the files.  However, for the files checked out from CVS,
there are no byte-compiled files. 

To build emacs from a CVS checkout, follow the instructions as you
would for the tarball, except that replace the initial 'make' by 'make
bootstrap', e.g.:

  $ ./configure
  $ make bootstrap

Re: NT Emacs make problem..

[D. Goel]

Thien-Thi Nguyen <ttn@glug.org> writes:

> Richard Stallman <rms@gnu.org> writes:

[...]

> 
> not really.  i get particular on build methodology and am likely to whine
> about other things (unproductively) if i get involved in this way.  perhaps
> D. Goel can supply the appropriate patch in addition to writing INSTALL-CVS.


Thi, sorry for the late follow-up. i don't know anything about CVS and
i am quite lost on the issue being discussed here, leave alone
thinking about a patch..  :)

in any case, RMS mentioned we need not add more instructions to
INSTALL-CVS itself.. the latter is, i guess, all ready, and i mailed
it to this ng in another mail....



DG				   <http://www.glue.umd.edu/~deego/>
-- 

Re: NT Emacs make problem..

[Kai Großjohann]

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

> Cool, we are done with this file then :).  I am including the file at
> the end of this mail.  perhaps, Could the maintainers please install it?

I still think it would be useful to say something about "make
bootstrap".  Suggestion A (to be appended to the previous text):

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

Suggestion B (also for append):

Note that "make bootstrap" overwrites some files which are under CVS
control (in particular, lisp/loaddefs.el and lisp/cus-load.el).  So
subsequent CVS updates might lead to CVS conflicts.  If such a
conflict arises, just overwrite your copy of the file with a clean
copy from the CVS repository, for example by issuing the following
command:

    cvs update -C lisp/cus-load.el

It's not clear to me which of the two suggestions should go in, but
at least one of them appears useful.  (Maybe you want both.)

Opinions?

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: NT Emacs make problem..

[Richard Stallman]

			  Building and Installing Emacs
				     from the CVS

      Copyright (c) 2001 Free Software Foundation, Inc.

If we treat the file as trivial, we shouldn't put on a copyright
notice either.  I suggest this short file:


	      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



Since this is so short, it would be nice not to have a separate file
for it.  If we put this into INSTALL, would it be conspicuous enough
for people to notice it?  I am not sure.  If people would overlook it
there, that would be a reason for a separat file.

Re: NT Emacs make problem..

[Eli Zaretskii]

On Tue, 11 Jun 2002, Richard Stallman wrote:

> Since this is so short, it would be nice not to have a separate file
> for it.  If we put this into INSTALL, would it be conspicuous enough
> for people to notice it?  I am not sure.  If people would overlook it
> there, that would be a reason for a separat file.

INSTALL is a very large file, so I'm afraid this info will get lost 
there.  I think a separate file is better, especially since more info 
will probably be added to it as time passes.

Re: NT Emacs make problem..

[Simon Josefsson]

On Tue, 11 Jun 2002, Richard Stallman wrote:

> Since this is so short, it would be nice not to have a separate file
> for it.  If we put this into INSTALL, would it be conspicuous enough
> for people to notice it?  I am not sure.  If people would overlook it
> there, that would be a reason for a separat file.

INSTALL-CVS or README-CVS is commonly used for this.  If it is in INSTALL 
very few will read it.

Re: NT Emacs make problem..

[Richard Stallman]

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

That is a good point.  We should state that.

    Note that "make bootstrap" overwrites some files which are under CVS
    control (in particular, lisp/loaddefs.el and lisp/cus-load.el).  So
    subsequent CVS updates might lead to CVS conflicts.

Why do conflicts happen here?  If you update these files locally based
on the sources as they are in CVS, and someone else updates the VCS
versions of these files also based on the sources as they are in CVS,
why doesn't CVS just say that the versions agree?  Is it because your
checked-out file has a different modtime than what is recorded in CVS?

If so, maybe we should use md5 checksums instead of file dates
in loaddefs.el to determine whether a file has changed.
Would that solve the problem?

As for cus-load.el, I don't see any reason why it would have such a
problem.  What is the reason?

Re: NT Emacs make problem..

[Richard Stallman]

    INSTALL is a very large file, so I'm afraid this info will get lost 
    there.  I think a separate file is better, especially since more info 
    will probably be added to it as time passes.

Ok.

Re: NT Emacs make problem..

[Stefan Monnier]

> If so, maybe we should use md5 checksums instead of file dates
> in loaddefs.el to determine whether a file has changed.

Please don't.  It would slow down the `make autoloads' step significantly.

> Would that solve the problem?

I"m not even sure it would.  Some of the reasons for conflicts can be that
you have local modifications so the md5sum would still be different.

BTW, I've recently changed the `-k' setting of loaddefs.el to `-kb'
which should mean that merging is never done any more (but you'll
probably need to check out a new workarea for the new setting to
take effect).  I haven't checked to see if I've made the change
correctly and if CVS implements it correctly, tho.


	Stef

Re: NT Emacs make problem..

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     Normally, it is not necessary to use "make bootstrap" after every CVS
>     update.  Unless there are problems, "make all" should be used.
>
> That is a good point.  We should state that.

OK.

>     Note that "make bootstrap" overwrites some files which are under CVS
>     control (in particular, lisp/loaddefs.el and lisp/cus-load.el).  So
>     subsequent CVS updates might lead to CVS conflicts.
>
> Why do conflicts happen here?

I don't know why the local files end up to be different than the
files on the server, but I see CVS conflicts from time to time.  (By
this I mean that "cvs update" reports the file as "C lisp/cus-load.el".)

I could wait for the next conflict and then look for the conflict
markers, then post my findings here.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: NT Emacs make problem..

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|>     Note that "make bootstrap" overwrites some files which are under CVS
|>     control (in particular, lisp/loaddefs.el and lisp/cus-load.el).  So
|>     subsequent CVS updates might lead to CVS conflicts.
|> 
|> Why do conflicts happen here?

Because loaddefs.el contains time stamps.

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: NT Emacs make problem..

[Eli Zaretskii]

On Wed, 12 Jun 2002, Stefan Monnier wrote:

> BTW, I've recently changed the `-k' setting of loaddefs.el to `-kb'

Yes, I noticed.  -kb also means that the nasty problems with Windows CVS 
clients that convert newlines to CR-LF pairs won't happen again.

> I haven't checked to see if I've made the change
> correctly and if CVS implements it correctly, tho.

It works for me, even on Windows (where text vs binary files are always a 
mess).

Re: NT Emacs make problem..

[D. Goel]

Richard Stallman <rms@gnu.org> writes:

>     Normally, it is not necessary to use "make bootstrap" after every CVS
>     update.  Unless there are problems, "make all" should be used.
> 
> That is a good point.  We should state that.
> 

Added to the file.  thanks.


DG				   <http://www.glue.umd.edu/~deego/>
-- 

Re: NT Emacs make problem..

[Richard Stallman]

    > Would that solve the problem?

    I"m not even sure it would.  Some of the reasons for conflicts can be that
    you have local modifications so the md5sum would still be different.

Regenerating loaddefs with local modifications will certainly
cause differences between your loaddefs and the standard one.
People who do that will have to cope with the consequences.

However, at present it seems that such differences occur even if you
have made no local modifications, which is a more common case and
encountered by people with less experience.  This is because the
modtime of the local checkout copy is different from the modtime of
someone else's checkout.  Using a checksum (md5 or other) instead
of the file modtime would solve that problem.

    which should mean that merging is never done any more (but you'll
    probably need to check out a new workarea for the new setting to
    take effect).

What are the results of this?

Re: NT Emacs make problem..

[Richard Stallman]

    I don't know why the local files end up to be different than the
    files on the server, but I see CVS conflicts from time to time.  (By
    this I mean that "cvs update" reports the file as "C lisp/cus-load.el".)

    I could wait for the next conflict and then look for the conflict
    markers, then post my findings here.

Please do that -- we should learn something from it.