Broken lisp/Makefile.w32-in

Broken lisp/Makefile.w32-in

[Tak Ota]

revision 1.21 of lisp/Makefile.w32-in is broken for --with-msvc
configuration.  The change below is responsible for this.  Reverting
it to revision 1.20 removes the problem in "make bootstrap"

2002-07-23  Andrew Innes  <andrewi@gnu.org>

	* makefile.w32-in (DONTCOMPILE): Remove cus-start.el.
	(DONTCOMPILE): Add various language files.
	(DONTCOMPILE): Remove term/xterm.el.
	(finder-inf.el): Remove.
	(update-authors): New target.
	(TAGS-LISP): Remove $(lispsource).
	(compile-always): Renamed from `compile-files'.
	(compile): New target, adapted from `compile-files'.
	(compile-calc): New target.
	(recompile): Change `.' to $(lisp).
	(bootstrap): Add update-subdirs and finder-data
	to dependencies; change compile-files to compile.

The makefile.w32-in contains the following target in both revision
1.20 and 1.21 however nothing depends on this target in 1.20.  It
appears like 1.21 is supposed to have made improvement by properly
depending on this target.

update-subdirs-CMD: doit
	@set QWINS=
	@for %d in ($(WINS)) do if not (%d)==(term) set QWINS=%QWINS% "%d"
	echo ;; In load-path, after this directory should come> subdirs.el
	echo ;; certain of its subdirectories.  Here we specify them.>> subdirs.el
	echo (normal-top-level-add-to-load-path $(SQUOTE)(%QWINS%))>> subdirs.el

I suspect the use of an environment variable above is flawed since
each action line is executed by independent shell (cmd.exe) thus the
variable QWINS is not shared.  It should be corrected to something
like this.

update-subdirs-CMD: doit
	echo ;; In load-path, after this directory should come> subdirs.el
	echo ;; certain of its subdirectories.  Here we specify them.>> subdirs.el
	echo (normal-top-level-add-to-load-path $(SQUOTE)(>> subdirs.el
	@for %d in ($(WINS)) do if not (%d)==(term) echo "%d">> subdirs.el
	echo ))>> subdirs.el

However, the 2002-07-23 changes have more than this and still fails
after this modification.

-Tak

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Tue, 30 Jul 2002 23:59:11 -0700 (PDT), Tak Ota <Takaaki.Ota@am.sony.com> wrote:

> revision 1.21 of lisp/Makefile.w32-in is broken for --with-msvc
> configuration.  The change below is responsible for this.  Reverting
> it to revision 1.20 removes the problem in "make bootstrap"

Yes.

> I suspect the use of an environment variable above is flawed since
> each action line is executed by independent shell (cmd.exe) thus the
> variable QWINS is not shared.

Yes. There's also another problem: the "compile-files" target was
renamed to "compile", but there's already a compile target in
Makefile.w32-in. With that bug, compiling Emacs tried to backup the .elc files,
which would fail if you didn't happen to have tar, for example.

I've commited a patch that reverts some of the changes by Andrew that
affect the MSVC/nmake build. With the patch, I can bootstrap and compile
without problem on a W2K.


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Richard Stallman]

    > revision 1.21 of lisp/Makefile.w32-in is broken for --with-msvc
    > configuration.  The change below is responsible for this.  Reverting
    > it to revision 1.20 removes the problem in "make bootstrap"

Is there a reason why this file is called makefile.w32-in rather than
Makefile.w32-in?

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Thu, 1 Aug 2002 10:52:32 -0600 (MDT), Richard Stallman <rms@gnu.org> wrote:

> Is there a reason why this file is called makefile.w32-in rather than
> Makefile.w32-in?

Not that I know of. That doesn't mean there is none.


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Tue, 30 Jul 2002 23:59:11 -0700 (PDT), Tak Ota <Takaaki.Ota@am.sony.com> wrote:

> It should be corrected to something
> like this.
> 
> update-subdirs-CMD: doit
> 	echo ;; In load-path, after this directory should come> subdirs.el
> 	echo ;; certain of its subdirectories.  Here we specify them.>> subdirs.el
> 	echo (normal-top-level-add-to-load-path $(SQUOTE)(>> subdirs.el
> 	@for %d in ($(WINS)) do if not (%d)==(term) echo "%d">> subdirs.el
> 	echo ))>> subdirs.el

Yes, that would work. Good!

Questions (to Andrew or anyone else that knows the answers :)

1.- Is there any reason for calc/ and obsolete/ not being in WINS?

2.- Why it is calc/ treated differently? (There's now a compile-calc
target.)

3.- Is there any relevancy in the order of directories passed to
`normal-top-level-add-to-load-path'? The flawed code in Makefile.w32-in
and the new above both generate the list in reverse order that the
current (CVS) contents of subdirs.el.


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Tue, 30 Jul 2002 23:59:11 -0700 (PDT), Tak Ota <Takaaki.Ota@am.sony.com> wrote:

> I suspect the use of an environment variable above is flawed since
> each action line is executed by independent shell (cmd.exe) thus the
> variable QWINS is not shared.  It should be corrected to something
> like this.
> 
> update-subdirs-CMD: doit
> 	echo ;; In load-path, after this directory should come> subdirs.el
> 	echo ;; certain of its subdirectories.  Here we specify them.>> subdirs.el
> 	echo (normal-top-level-add-to-load-path $(SQUOTE)(>> subdirs.el
> 	@for %d in ($(WINS)) do if not (%d)==(term) echo "%d">> subdirs.el
> 	echo ))>> subdirs.el

Before commiting this code to lisp/makefile.w32-in, "nmake
update-subdirs" didn't work in any Windows target that I tried. With it,
updating subdirs works in modern Windows, but still fails on W95 with
COMMAND.COM (the "for" somehow manages to send just one directory to
subdirs.el). I'm not sure about W98 and Me, although I'd love to know.

There's no question that the Windows port should continue supporting
*running* in old W95 and W98 machines, but it is really worthwhile to
continue supporting *building* on those machines?

I'd bet Emacs users on W95/98 do use binary tarballs and don't build
their own Emacs.

And there aren't many developers working on W95 either, because a recent
bug with stat() in HEAD that totally precluded compiling Emacs stood
unfixed for about a month without a single bug report about it.


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

> From: Juanma Barranquero <lektu@terra.es>
> Date: Fri, 30 Aug 2002 14:14:19 +0200
> 
> > 	echo (normal-top-level-add-to-load-path $(SQUOTE)(>> subdirs.el
> > 	@for %d in ($(WINS)) do if not (%d)==(term) echo "%d">> subdirs.el
> > 	echo ))>> subdirs.el
> 
> Before commiting this code to lisp/makefile.w32-in, "nmake
> update-subdirs" didn't work in any Windows target that I tried. With it,
> updating subdirs works in modern Windows, but still fails on W95 with
> COMMAND.COM (the "for" somehow manages to send just one directory to
> subdirs.el).

Can you figure out why is that failing?  Could it be that $WINS is so
long that the resulting command exceeds the 126-character limit on
COMMAND.COM's command line, for example?

> I'm not sure about W98 and Me, although I'd love to know.

They both use COMMAND.COM, so the same problems should show up.

> There's no question that the Windows port should continue supporting
> *running* in old W95 and W98 machines, but it is really worthwhile to
> continue supporting *building* on those machines?

IMHO, if it's feasible to support building on those systems, we should
do that.  Windows 98 SE is still a very popular version of Windows (I,
for one, prefer it to both Windows/ME and W2K/XP).

> I'd bet Emacs users on W95/98 do use binary tarballs and don't build
> their own Emacs.

I think _most_ Windows users download prebuilt binaries, even on W2K
and Windows/XP.

Re: Broken lisp/Makefile.w32-in

[Kim F. Storm]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> 
> > There's no question that the Windows port should continue supporting
> > *running* in old W95 and W98 machines, but it is really worthwhile to
> > continue supporting *building* on those machines?
> 
> IMHO, if it's feasible to support building on those systems, we should
> do that.  Windows 98 SE is still a very popular version of Windows (I,
> for one, prefer it to both Windows/ME and W2K/XP).

It's been a long time since I tried to build on Windoze, but if I ever
need to do that again, I'll prefer to do it with the 98SE version I
have [and paid for], as I see no reason to pay M$ for yet another
piece of non-free software.

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

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

> Can you figure out why is that failing?  Could it be that $WINS is so
> long that the resulting command exceeds the 126-character limit on
> COMMAND.COM's command line, for example?

I'll try to check it.

> IMHO, if it's feasible to support building on those systems, we should
> do that.

OK.

> Windows 98 SE is still a very popular version of Windows (I,
> for one, prefer it to both Windows/ME and W2K/XP).

Curious. I find both NT 4.0 and W2K to be exceptionally stable (XP is
less so IMHO).

> I think _most_ Windows users download prebuilt binaries, even on W2K
> and Windows/XP.

Well, yes, but supporting building on W2K/XP does not pose any problem
because CMD.EXE is quite more powerful than COMMAND.COM :)

-- 
Juanma Barranquero <lektu@terra.es>

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

On Sat, 31 Aug 2002, Juanma Barranquero wrote:

> > Windows 98 SE is still a very popular version of Windows (I,
> > for one, prefer it to both Windows/ME and W2K/XP).
> 
> Curious. I find both NT 4.0 and W2K to be exceptionally stable (XP is
> less so IMHO).

I wasn't thinking about stability (although my Windows 98SE machine stays 
up for months on end without crashing).  I was talking about usability 
and back-compatibility.  Too many old programs don't work on W2K/XP, and 
too many little but valuable features are unavailable there but available 
in 98SE.

> Well, yes, but supporting building on W2K/XP does not pose any problem
> because CMD.EXE is quite more powerful than COMMAND.COM :)

I think the real problem with that is not COMMAND.COM per se (after all, 
the MS-DOS build uses _only_ COMMAND.COM and doesn't have any trouble), 
but rather the need to support COMMAND.COM, CMD.EXE, and the Cygwin/MinGW
environment at the same time and with the same Makefile's.

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Sun, 1 Sep 2002 07:11:37 +0200 (IST)
Eli Zaretskii <eliz@is.elta.co.il> wrote:

> I was talking about usability and back-compatibility.

Back-compatibility for sure (no gamer I know would touch NT/2K/XP with a
ten feet pole, for example). But usability is highly subjective, of
course; I find XP the most usable and likable of all Windows I've tried.

> I think the real problem [...] the need to support COMMAND.COM, CMD.EXE,
> and the Cygwin/MinGW environment at the same time and with the same
> Makefile's.

Yes.

-- 
Juanma Barranquero <lektu@terra.es>

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Fri, 30 Aug 2002 22:06:45 +0300
"Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> Can you figure out why is that failing?

A bug in command.com's handling of "if" on for loops, I'd say. Consider
this test program:

 @echo off
 del test.txt
 for %%i in (*.*) do echo "%%i" >> test.txt
 echo ==========================
 type test.txt
 echo ==========================

Running it in a directory with files file[1-3].bat gives:

 ==========================
 "FILE2.BAT"
 "TEST.TXT"
 "FILE1.BAT"
 "FILE3.BAT"
 ==========================

However, substituting the "for" with:

 for %%i in (*.*) do if 1==1 echo "%%i" >> test.txt

the result is now:

 "TEST.TXT"
 "FILE1.BAT"
 "FILE3.BAT"
 ==========================
 "FILE2.BAT"
 ==========================



-- 
Juanma Barranquero <lektu@terra.es>

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

On Sat, 31 Aug 2002, Juanma Barranquero wrote:

>  @echo off
>  del test.txt
>  for %%i in (*.*) do echo "%%i" >> test.txt
>  echo ==========================
>  type test.txt
>  echo ==========================
> 
> Running it in a directory with files file[1-3].bat gives:
> 
>  ==========================
>  "FILE2.BAT"
>  "TEST.TXT"
>  "FILE1.BAT"
>  "FILE3.BAT"
>  ==========================
> 
> However, substituting the "for" with:
> 
>  for %%i in (*.*) do if 1==1 echo "%%i" >> test.txt
> 
> the result is now:
> 
>  "TEST.TXT"
>  "FILE1.BAT"
>  "FILE3.BAT"
>  ==========================
>  "FILE2.BAT"
>  ==========================

Is this really directly related to the actual problem?  What I see in the 
example is that writes to the screen are out of order; how does this 
explain the problem with the build which I thought was caused by the list 
of files beaing shorter than it should have been?

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Sun, 1 Sep 2002 07:15:56 +0200 (IST)
Eli Zaretskii <eliz@is.elta.co.il> wrote:

> Is this really directly related to the actual problem?  What I see in the 
> example is that writes to the screen are out of order; 

Ahem, what you see is that in one case every string output by the echo
goes to the file, while in the second case only the first string goes to
the file; the others go directly to the standard output. So redirection
is working differently when the command executed in each "for" iteration
is an "if" and when it isn't (unless I'm understanding erroneously what
"for" and "if" should do...).

> how does this 
> explain the problem with the build which I thought was caused by the list 
> of files beaing shorter than it should have been?

In the makefile the command is almost exactly like the one in this
example, with the same effect: only the first directory goes to
subdirs.el, the others are just output to the screen.

-- 
Juanma Barranquero <lektu@terra.es>

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

> Date: Sun, 01 Sep 2002 16:58:17 -0300
> From: Juanma Barranquero <lektu@terra.es>
> 
> Ahem, what you see is that in one case every string output by the echo
> goes to the file, while in the second case only the first string goes to
> the file; the others go directly to the standard output.

Ah, sorry, I wasn't aware of that (you didn't show the file created
by the command, so I was confused).

Does it help to put the redirection at the beginning of the command,
like below?

  >> foo.txt for ...

(yes, it's a valid syntax for COMMAND.COM and CMD.EXE).

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Sun, 01 Sep 2002 19:59:58 +0300, "Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> Ah, sorry, I wasn't aware of that (you didn't show the file created
> by the command, so I was confused).

Uh? In my example, the "for" redirects to test.txt, and the bat file
then "types" the contents of test.txt surrounded by rows of "=" to
differentiate any other posible output from the contents of test.txt.

That's why in the first example (without "if") all output is between the
equal-sign rows: is the contents of the redirected file, while in the
second example (with "if"), first there's unwanted output to the screen
and then test.txt is typed, showing that it does contain just a single
line...

> Does it help to put the redirection at the beginning of the command,
> like below?

I'll try it at home ASAP. Thanks.

> (yes, it's a valid syntax for COMMAND.COM and CMD.EXE).

Live and learn :-)


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

On Mon, 2 Sep 2002, Juanma Barranquero wrote:

> On Sun, 01 Sep 2002 19:59:58 +0300, "Eli Zaretskii" <eliz@is.elta.co.il> wrote:
> 
> > Ah, sorry, I wasn't aware of that (you didn't show the file created
> > by the command, so I was confused).
> 
> Uh? In my example, the "for" redirects to test.txt, and the bat file
> then "types" the contents of test.txt surrounded by rows of "=" to
> differentiate any other posible output from the contents of test.txt.

Yes, but when everything is shown together, and the output describes a 
bug, it's hard to be sure that the "===" delimiters are indeed 
trustworthy.
> > Does it help to put the redirection at the beginning of the command,
> > like below?
> 
> I'll try it at home ASAP. Thanks.

Thank you.

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Sun, 01 Sep 2002 19:59:58 +0300, "Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> Does it help to put the redirection at the beginning of the command,
> like below?
> 
>   >> foo.txt for ...

It does in the command line, but no from inside the makefile. nmake
complains that it cannot execute the "for" command.

As a last resort I can split WINS into two variables, like

 WINS_NO_TERM=\
	calc \
	calendar \
	etc ... \

 WINS=$(WINS_NO_TERM) term

and use WINS_NO_TERM in update-subdirs, but that's just an *ugly* hack :)


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

On Wed, 4 Sep 2002, Juanma Barranquero wrote:

> On Sun, 01 Sep 2002 19:59:58 +0300, "Eli Zaretskii" <eliz@is.elta.co.il> wrote:
> 
> > Does it help to put the redirection at the beginning of the command,
> > like below?
> > 
> >   >> foo.txt for ...
> 
> It does in the command line, but no from inside the makefile. nmake
> complains that it cannot execute the "for" command.

How about if you invoke command.com explicitly, like this:

	command.com /c for .... >>foo.txt

(If this works, we will have a problem of figuring out when to use 
command.com and when cmd.exe, but it might nevertheless be worthwhile to
know whether the bug goes away this way.)

> As a last resort I can split WINS into two variables, like
> 
>  WINS_NO_TERM=\
> 	calc \
> 	calendar \
> 	etc ... \
> 
>  WINS=$(WINS_NO_TERM) term
> 
> and use WINS_NO_TERM in update-subdirs, but that's just an *ugly* hack :)

If it does the job, there's nothing ugly about it.  Windows shells are 
themselves ugly hacks, so any means of getting them to do what we want is 
IMHO justified ;-)

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Thu, 5 Sep 2002 07:08:09 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> How about if you invoke command.com explicitly, like this:
> 
> 	command.com /c for .... >>foo.txt

I'll have to test it tonight at home, but I don't see how could it work,
because, as my example .BAT file showed, the bug with "for", "if" and
redirection happens also in the command line (or at least inside a .BAT
file) and is not related to nmake.

> Windows shells are themselves ugly hacks, so any means of getting them
> to do what we want is IMHO justified ;-)

Also sprach Machiavelli ;-)

Anyway, does anyone know why term/ shouldn't be included in subdirs.el?


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Andreas Schwab]

Juanma Barranquero <lektu@terra.es> writes:

|> Anyway, does anyone know why term/ shouldn't be included in subdirs.el?

AFAIK it's because the files in it should only be referenced with the
term/ prefix.

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: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

On Thu, 5 Sep 2002, Juanma Barranquero wrote:

> On Thu, 5 Sep 2002 07:08:09 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:
> 
> > How about if you invoke command.com explicitly, like this:
> > 
> > 	command.com /c for .... >>foo.txt
> 
> I'll have to test it tonight at home, but I don't see how could it work,
> because, as my example .BAT file showed, the bug with "for", "if" and
> redirection happens also in the command line (or at least inside a .BAT
> file) and is not related to nmake.

I'm guessing you are unaware of how ugly things can get with COMMAND.COM 
when redirection of built-in commands and especially batch files is 
involved.  For starters, you cannot redirect output of a batch file
at all(!).  Try it:

  C:\> type foo.bat
  echo Hi there
  C:\> foo > foo.txt
  Hi there
  C:\>

In other words, the output of `echo' still goes to the screen even though 
you've redirected it to foo.txt.  Now try this, and observe the change:

  C:\> command.com /c foo.bat > foo.txt

I suspect that something similar might happen with a FOR loop.

When you invoke "command.com /c ... >>foo.txt", the situation is 
different: here, the subsidiary COMMAND.COM does not redirect any output 
of FOR.  Instead, it is invoked by the parent shell with its stdout 
already redirected to a file.  Since COMMAND.COM is just a program, not a 
batch file or internal command like FOR, redirection of its output works 
much more reliably.

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Thu, 5 Sep 2002 16:57:30 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> I'm guessing you are unaware of how ugly things can get with COMMAND.COM 
> when redirection of built-in commands and especially batch files is 
> involved.

You're right, I was unaware. :)


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Thu, 5 Sep 2002 07:08:09 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> How about if you invoke command.com explicitly, like this:
> 
> 	command.com /c for .... >>foo.txt

I couldn't make it work, it didn't write any directory to subdirs.el.

> If it does the job, there's nothing ugly about it.

BTW, would it be OK to install some of the lisp/makefile.w32-in changes
into 21_1_RC? That way the update-subdirs target would at least work in
NT/2K/XP platforms. (And the WINS/WINS_WITHOUT_TERM hack can be
installed if necessary to make it work also in 95/98/Me.)


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

> Date: Fri, 06 Sep 2002 12:47:53 +0200
> From: Juanma Barranquero <lektu@terra.es>
> 
> > How about if you invoke command.com explicitly, like this:
> > 
> > 	command.com /c for .... >>foo.txt
> 
> I couldn't make it work, it didn't write any directory to subdirs.el.

Does it work to have the ``for ...'' part be in a batch file which is
then invoked as "command.com /c foo.bat ..foo.txt"?

> BTW, would it be OK to install some of the lisp/makefile.w32-in changes
> into 21_1_RC? That way the update-subdirs target would at least work in
> NT/2K/XP platforms. (And the WINS/WINS_WITHOUT_TERM hack can be
> installed if necessary to make it work also in 95/98/Me.)

I'm not sure I know what changes you have in mind.  Could you please
post a diff?

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Wed, 18 Sep 2002 09:43:27 +0300, "Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> Does it work to have the ``for ...'' part be in a batch file which is
> then invoked as "command.com /c foo.bat ..foo.txt"?

I'll have to test it.

> I'm not sure I know what changes you have in mind.  Could you please
> post a diff?

Yes. Basically I'm thinking of bringing to EMACS_21_1_RC/lisp/makefile.w32-in
some of the changes for the better that have been integrated into the RC
line. AFAIK, with those changes the make process works better in some
environments (you can do now "nmake updates" in Windows NT/2K/XP) and no
worse in any one.

bootstrap still doesn't make the update-subdirs target, though that
could be added if your command/c foo.bat method works, or via the
WINS/WINS_WITHOUT_TERM kludge.


                                                           /L/e/k/t/u



Index: makefile.w32-in
===================================================================
RCS file: /cvs/emacs/lisp/makefile.w32-in,v
retrieving revision 1.16
diff -u -2 -r1.16 makefile.w32-in
--- makefile.w32-in	16 Aug 2001 13:17:32 -0000	1.16
+++ makefile.w32-in	20 Sep 2002 08:17:35 -0000
@@ -28,4 +28,5 @@
 
 lisp = $(CURDIR)
+srcdir = $(CURDIR)/..
 
 # You can specify a different executable on the make command line,
@@ -46,5 +47,8 @@
 ETAGS = "../lib-src/$(BLD)/etags"
 
-# Files which should not be compiled.
+# Files which should not be compiled.  If you change the name `DONTCOMPILE'
+# to something different, you'll have to change make-dist as well, and
+# modify the lists in $lisp and $shortlisp on src/Makefile.in.
+#
 # - emacs-lisp/cl-specs.el:  only contains `def-edebug-spec's so there's
 #   no point compiling it, although it doesn't hurt.
@@ -135,8 +139,10 @@
 	mail \
 	net \
+	obsolete \
 	play \
 	progmodes \
 	term \
-	textmodes
+	textmodes \
+	toolbar
 
 doit:
@@ -148,8 +154,5 @@
 	-$(emacs) -l cus-dep --eval $(ARGQUOTE)(setq find-file-hooks nil)$(ARGQUOTE) -f custom-make-dependencies $(lisp) $(WINS)
 
-finder-inf.el:
-	echo (provide $(SQUOTE)finder-inf)>> $@
-
-finder-data: finder-inf.el doit
+finder-data: doit
 	@echo Directories: $(WINS)
 	$(emacs) -l finder -f finder-compile-keywords-make-dist $(lisp) $(WINS)
@@ -182,9 +185,9 @@
 
 update-subdirs-CMD: doit
-	@set QWINS=
-	@for %d in ($(WINS)) do if not (%d)==(term) set QWINS=%QWINS% "%d"
 	echo ;; In load-path, after this directory should come> subdirs.el
 	echo ;; certain of its subdirectories.  Here we specify them.>> subdirs.el
-	echo (normal-top-level-add-to-load-path $(SQUOTE)(%QWINS%))>> subdirs.el
+	echo (normal-top-level-add-to-load-path $(SQUOTE)(>> subdirs.el
+	@for %d in ($(WINS)) do if not (%d)==(term) echo "%d">> subdirs.el
+	echo ))>> subdirs.el
 
 update-subdirs-SH: doit
@@ -196,4 +199,9 @@
 updates: update-subdirs autoloads finder-data custom-deps
 
+# Update the AUTHORS file.
+
+update-authors:
+	$(emacs) -f batch-update-authors $(srcdir)/AUTHORS $(srcdir)
+
 TAGS: $(lisptagsfiles1) $(lisptagsfiles2)
 	$(ETAGS) $(lisptagsfiles1) $(lisptagsfiles2)
@@ -210,6 +218,8 @@
 	-$(DEL) $@
 
-# Compile all Lisp files, except those from DONTCOMPILE.  This
-# compiles files unconditionally.  All .elc files are made writable
+# Compile all Lisp files, except those from DONTCOMPILE,
+# but don't recompile those that are up to date.
+
+# All .elc files are made writable
 # before compilation in case we checked out read-only (CVS option -r).
 # Files MUST be compiled one by one.  If we compile several files in a
@@ -220,12 +230,12 @@
 
 # Need separate version for sh and native cmd.exe
-compile-files: subdirs.el compile-files-$(SHELLTYPE) doit
+compile: subdirs.el compile-$(SHELLTYPE) doit
 
-compile-files-CMD:
+compile-CMD:
 #	-for %f in ($(lisp) $(WINS)) do for %g in (%f\*.elc) do @attrib -r %g
 	for %f in ($(COMPILE_FIRST)) do $(emacs) -f batch-byte-compile %f
 	for %f in (. $(WINS)) do for %g in (%f/*.el) do $(emacs) -f batch-byte-compile %f/%g
 
-compile-files-SH:
+compile-SH:
 #	for elc in $(lisp)/*.elc $(lisp)/*/*.elc; do attrib -r $$elc; done
 	for el in $(COMPILE_FIRST); do \
@@ -235,6 +245,31 @@
 	for dir in $(lisp) $(WINS); do \
 	  for el in $$dir/*.el; do \
+	    if test -f $$el; \
+	    then \
+	      echo Compiling $$el; \
+	      $(emacs) -f batch-byte-compile-if-not-done $$el; \
+	    fi \
+	  done; \
+	done
+
+# Compile all Lisp files, except those from DONTCOMPILE.  This
+# is like `compile' but compiles files unconditionally.
+compile-always: subdirs.el compile-always-$(SHELLTYPE) doit
+
+compile-always-CMD:
+#	-for %f in ($(lisp) $(WINS)) do for %g in (%f\*.elc) do @attrib -r %g
+	for %f in ($(COMPILE_FIRST)) do $(emacs) -f batch-byte-compile %f
+	for %f in (. $(WINS)) do for %g in (%f/*.el) do $(emacs) -f batch-byte-compile %f/%g
+
+compile-always-SH:
+#	for elc in $(lisp)/*.elc $(lisp)/*/*.elc; do attrib -r $$elc; done
+	for el in $(COMPILE_FIRST); do \
+	  echo Compiling $$el; \
+	  $(emacs) -f batch-byte-compile $$el || exit 1; \
+	done
+	for dir in $(lisp) $(WINS); do \
+	  for el in $$dir/*.el; do \
 	    echo Compiling $$el; \
-	    $(emacs) -f batch-byte-compile $$el; \
+	    $(emacs) -f batch-byte-compile $$el || exit 1; \
 	  done; \
 	done
@@ -249,5 +284,5 @@
 # Compile Lisp files, but save old compiled files first.
 
-compile: backup-compiled-files compile-files
+compile-after-backup: backup-compiled-files compile-always
 
 # Recompile all Lisp files which are newer than their .elc files.
@@ -256,5 +291,5 @@
 
 recompile: doit
-	$(emacs) -f batch-byte-recompile-directory .
+	$(emacs) -f batch-byte-recompile-directory $(lisp)
 
 # Prepare a bootstrap in the lisp subdirectory.  Build loaddefs.el,
@@ -268,14 +303,15 @@
 
 bootstrap-clean-CMD:
-	if exist $(EMACS) $(MAKE) $(MFLAGS) autoloads
+#	if exist $(EMACS) $(MAKE) $(MFLAGS) autoloads
 	-for %f in (. $(WINS)) do for %g in (%f\*.elc) do @$(DEL) %g
 
 bootstrap-clean-SH:
-	if test -f $(EMACS); then $(MAKE) $(MFLAGS) autoloads; fi
-	-rm -f $(lisp)/*.elc $(lisp)/*/*.elc
+#	if test -f $(EMACS); then $(MAKE) $(MFLAGS) autoloads; fi
+#	-rm -f $(lisp)/*.elc $(lisp)/*/*.elc
+	-for dir in . $(WINS); do rm -f $$dir/*.elc; done
 
 # Generate/update files for the bootstrap process.
 
-bootstrap: autoloads compile-files custom-deps
+bootstrap: autoloads compile finder-data custom-deps
 
 #

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

> Date: Fri, 20 Sep 2002 10:26:46 +0200
> From: Juanma Barranquero <lektu@terra.es>
> 
> > I'm not sure I know what changes you have in mind.  Could you please
> > post a diff?
> 
> Yes. Basically I'm thinking of bringing to EMACS_21_1_RC/lisp/makefile.w32-in
> some of the changes for the better that have been integrated into the RC
> line.

I don't object to the changes you posted, assuming they have been (or
will be ;-) tested on both NT-family and Windows 9X family of systems.

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Sat, 21 Sep 2002 00:23:08 +0300
"Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> I don't object to the changes you posted, assuming they have been (or
> will be ;-) tested on both NT-family and Windows 9X family of systems.

Will be ;-)

But I can only test on W2K and W95, I have no other Windows machine at
hand.

-- 
Juanma Barranquero <lektu@terra.es>

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

On Sun, 22 Sep 2002, Juanma Barranquero wrote:

> But I can only test on W2K and W95, I have no other Windows machine at
> hand.

I think W2K and W95 will be sufficient to be sure the change will work 
reasonably well.

Thanks.

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

<sigh> Another problem with lisp/Makefile.w32-in and bootstraping.

After nmake bootstrap, the DONTCOMPILE files are compiled.

This can cause problems. For example, eshell/esh-maint.el gets compiled
and then during compilation the eshell/*.el files include esh-maint.elc;
at run-time they crash because `assert' and other functions from cl-macs
are not defined.

AFAIK, this happens also in EMACS_21_1_RC.

lisp/makefile.w32-in has these lines:

$(DONTCOMPILE:.el=.elc):
        -$(DEL) $@

but I'm not sure if they're a leftover from lisp/makefile.in.

I don't see any easy way to keep the DONTCOMPILE files from being
compiled. Deleting the .elc afterwards would be easier, but that doesn't
work.

Any ideas?


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Stefan Monnier]

> <sigh> Another problem with lisp/Makefile.w32-in and bootstraping.
> 
> After nmake bootstrap, the DONTCOMPILE files are compiled.
> 
> This can cause problems. For example, eshell/esh-maint.el gets compiled
> and then during compilation the eshell/*.el files include esh-maint.elc;
> at run-time they crash because `assert' and other functions from cl-macs
> are not defined.
> 
> AFAIK, this happens also in EMACS_21_1_RC.
> 
> lisp/makefile.w32-in has these lines:
> 
> $(DONTCOMPILE:.el=.elc):
>         -$(DEL) $@
> 
> but I'm not sure if they're a leftover from lisp/makefile.in.
> 
> I don't see any easy way to keep the DONTCOMPILE files from being
> compiled. Deleting the .elc afterwards would be easier, but that doesn't
> work.
> 
> Any ideas?

Check out the end of loaddefs.el.  There's a `no-byte-compile'
local variable that you can set in the `local variables' section.
It's much better than DONTCOMPILE.


	Stefan

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Tue, 24 Sep 2002 14:03:13 -0400, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> Check out the end of loaddefs.el.  There's a `no-byte-compile'
> local variable that you can set in the `local variables' section.
> It's much better than DONTCOMPILE.

Yes, I know about no-byte-compile.

I had (perhaps erroneously) supposed there's a reason why some files are
excluded from compilation through the makefile and not via a Local
Variables section (perhaps they're compiled in some phase of the
bootstrapping, or just in some platforms). Isn't? Would it be OK to add
Local Variables sections to those .el files?

Puzzled but thankful,

                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Stefan Monnier]

> > Check out the end of loaddefs.el.  There's a `no-byte-compile'
> > local variable that you can set in the `local variables' section.
> > It's much better than DONTCOMPILE.
> 
> Yes, I know about no-byte-compile.
> 
> I had (perhaps erroneously) supposed there's a reason why some files are
> excluded from compilation through the makefile and not via a Local
> Variables section (perhaps they're compiled in some phase of the
> bootstrapping, or just in some platforms). Isn't?

Because the `no-byte-compile' variable (which has been in loaddefs.el
for as long as I can remember) has only been obeyed by bytecomp.el recently.

Why did people use DONTCOMPILE instead of fixing bytecomp.el, I do not know.

> Would it be OK to add Local Variables sections to those .el files?

Of course,


	Stefan

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Wed, 25 Sep 2002 10:30:16 -0400, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> > Would it be OK to add Local Variables sections to those .el files?
> 
> Of course,

We're talking of modifying ~50 files, so I'd rather ask for confirmation before
going on.

Does anyone oppose to adding a Local Variables section with
"no-byte-compile: t" to the DONTCOMPILE files?

Thanks,

                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Richard Stallman]

    Does anyone oppose to adding a Local Variables section with
    "no-byte-compile: t" to the DONTCOMPILE files?

Doing it in the first line is cleaner.

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Tue, 01 Oct 2002 02:18:03 -0400, Richard Stallman <rms@gnu.org> wrote:

> Doing it in the first line is cleaner.

Curious. There's no single .el file in the HEAD with no-byte-compile in
the first line, while there are about 10 (some of them automatically
generated) with no-byte-compile in a Local Variables section.

                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Sat, 21 Sep 2002 00:23:08 +0300
"Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> I don't object to the changes you posted, assuming they have been (or
> will be ;-) tested on both NT-family and Windows 9X family of systems.

I'm trying to test them, but I'm unable to bootstrap EMACS_21_1_RC on
W95 (with or without my changes) because of a problem with
`grep-compute-defaults' during the making of the custom-deps target:

> Saving file c:/BIN/emacs/EMACS_21_1_RC/lisp/cus-load.el...
> Symbol's function definition is void: grep-compute-defaults

AFAICS, progmodes/compile.el has extensive changes in HEAD, including
moving that function near the top to preclude problems with custom
declarations.

Another problem: several targets (bootstrap-clean, compile-files, etc.) do
nested fors, and COMMAND.COM chokes on them.

And finally a question: why is bootstrapping contingent on having a diff
program (and maybe also grep, I'm not sure)?


-- 
Juanma Barranquero <lektu@terra.es>

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

> Date: Sun, 29 Sep 2002 02:43:03 -0300
> From: Juanma Barranquero <lektu@terra.es>
> 
> I'm trying to test them, but I'm unable to bootstrap EMACS_21_1_RC on
> W95 (with or without my changes) because of a problem with
> `grep-compute-defaults' during the making of the custom-deps target:
> 
> > Saving file c:/BIN/emacs/EMACS_21_1_RC/lisp/cus-load.el...
> > Symbol's function definition is void: grep-compute-defaults

Sorry, cannot help you here: I never saw anything like that.  (But I
didn't try to bootstrap on Windows 9X either.)

> Another problem: several targets (bootstrap-clean, compile-files, etc.) do
> nested fors, and COMMAND.COM chokes on them.

If you cannot work around this, perhaps we should require Bash on
Windows 9X?

> And finally a question: why is bootstrapping contingent on having a diff
> program (and maybe also grep, I'm not sure)?

What parts of the bootstrap need those programs?

Re: Broken lisp/Makefile.w32-in

[Stefan Monnier]

> > Another problem: several targets (bootstrap-clean, compile-files, etc.) do
> > nested fors, and COMMAND.COM chokes on them.
> 
> If you cannot work around this, perhaps we should require Bash on
> Windows 9X?
> 
> > And finally a question: why is bootstrapping contingent on having a diff
> > program (and maybe also grep, I'm not sure)?
> 
> What parts of the bootstrap need those programs?

And I don't see anything wrong with requiring such things.
After all, we also require TeXinfo-4.2, based on the idea that people
working from the CVS can be expected to have more tools available
(and more uptodate ones) than people using distribution tarballs.


	Stefan

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Sun, 29 Sep 2002 15:53:47 -0400
"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> And I don't see anything wrong with requiring such things.
> After all, we also require TeXinfo-4.2, based on the idea that people
> working from the CVS can be expected to have more tools available
> (and more uptodate ones) than people using distribution tarballs.

Yeah, but these requirements aren't documented. Trying to bootstrap
Emacs on a W95 is really painful. I know what I'm doing (or so I think),
and I've never been able to build it by doing:

configure --with-msvc
nmake bootstrap

in a Windows 95. I've needed some cygwin or mingw tools, I've done some
parts of the bootstraping manually, I've had to use 4DOS instead of
COMMAND.COM in some steps of the process (because COMMAND.COM just
wouldn't cut it), but COMMAND.COM in others (because of
incompatibilities of 4DOS.COM), move to the lisp/ directories and
compile the .el files with a "for %i in (*.el)", etc...

OK, as Richard says, most Windows users won't ever bootstrap Emacs.
Perhaps we should abandon the fiction that bootstrapping with
COMMAND.COM is supported, and just say "You're on your own" in the
documentation. I don't know why am I spending time trying to make it
work.

-- 
Juanma Barranquero <lektu@terra.es>

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Sun, 29 Sep 2002 19:38:08 +0300
"Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> Sorry, cannot help you here: I never saw anything like that.  (But I
> didn't try to bootstrap on Windows 9X either.)

I'm starting to think I'm the only one who ever tries it, and in a few
weeks I'm gonna switch to XP Home Edition and I wonder who'll check
W95/98/Me builds then...

> If you cannot work around this, perhaps we should require Bash on
> Windows 9X?

Hmm, that would be tantamount to requiring cygwin/mingw tools. I'd
rather not. Perhaps the right answer is not to try to conflate in just
one makefile support for bash, cmd.exe and command.com. I don't know.

> What parts of the bootstrap need those programs?

Don't know, but it failed when I took the mingw tools out of my PATH.

-- 
Juanma Barranquero <lektu@terra.es>

Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii]

On Sun, 29 Sep 2002, Juanma Barranquero wrote:

> > If you cannot work around this, perhaps we should require Bash on
> > Windows 9X?
> 
> Hmm, that would be tantamount to requiring cygwin/mingw tools. I'd
> rather not.

It's painful, but if that's the only reasonable way to do that on Windows 
9X, I don't see why we should drop the idea.  It's certainly better than 
to tell that bootstrap is impossible on Windows 9X.

Re: Broken lisp/Makefile.w32-in

[Richard Stallman]

    I'm trying to test them, but I'm unable to bootstrap EMACS_21_1_RC on
    W95 (with or without my changes) because of a problem with
    `grep-compute-defaults' during the making of the custom-deps target:

    > Saving file c:/BIN/emacs/EMACS_21_1_RC/lisp/cus-load.el...
    > Symbol's function definition is void: grep-compute-defaults

Thanks.  I will fix that.

    And finally a question: why is bootstrapping contingent on having a diff
    program (and maybe also grep, I'm not sure)?

I don't know, but since ordinary users don't ave to do bootstrapping,
I don't see much harm in needing them.

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Sun, 29 Sep 2002 14:44:07 -0400, Richard Stallman <rms@gnu.org> wrote:

> Thanks.  I will fix that.

Moving grep-compute-defaults near the top isn't enough. I still get the
same error while trying to bootstrap in W95.


                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Richard Stallman]

    > Thanks.  I will fix that.

    Moving grep-compute-defaults near the top isn't enough. I still get the
    same error while trying to bootstrap in W95.

That is quite surprising.  Does bootstrapping rebuild loaddefs.el?
Could you possibly debug this (since I don't know if we have anyone
else)?

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Tue, 01 Oct 2002 09:38:27 -0400, Richard Stallman <rms@gnu.org> wrote:

> That is quite surprising.  Does bootstrapping rebuild loaddefs.el?

Not sure, but I tried rebuilding it and then re-bootstrapping and I
still didn't get it to work.

> Could you possibly debug this (since I don't know if we have anyone
> else)?

I'll do if/when I get time to spare on it.

                                                           /L/e/k/t/u

Re: Broken lisp/Makefile.w32-in

[Richard Stallman]

    There's no question that the Windows port should continue supporting
    *running* in old W95 and W98 machines, but it is really worthwhile to
    continue supporting *building* on those machines?

Yes.

    I'd bet Emacs users on W95/98 do use binary tarballs and don't build
    their own Emacs.

If they encounter bugs, we will ASK them to build from the source,
so it ought to build from the source.

Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero]

On Fri, 30 Aug 2002 15:18:35 -0400
Richard Stallman <rms@gnu.org> wrote:

> Yes.

Ok.

> If they encounter bugs, we will ASK them to build from the source,
> so it ought to build from the source.

That's wishfull thinking IMHO. Most W95/98/Me users who could report a
problem with Emacs won't have either MSVC or gcc/mingw installed. If
there were many of them, some would show up on emacs-devel sooner or
later, wouldn't they? :-)

But I'm not pushing my point. I'll try to fix the problem.


-- 
Juanma Barranquero <lektu@terra.es>