Failed to compile from last bzr repo

Failed to compile from last bzr repo

[Bastien]

Hi all,

I just checked out the bzr repo and cannot compile with this error:

In toplevel form:
emacs-lisp/byte-opt.el:247:1:Error: Unknown upattern `(let env nil)'
make[2]: *** [/home/guerry/install/bzr/emacs/build/lisp/emacs-lisp/byte-opt.elc] Erreur 1
make[2]: quittant le répertoire « /home/guerry/install/bzr/emacs/build/lisp »
make[1]: *** [bootstrap-emacs] Erreur 2
make[1]: quittant le répertoire « /home/guerry/install/bzr/emacs/build/src »
make: *** [src] Erreur 2

Let me know if you need more info.

Thanks,

-- 
 Bastien

Re: Failed to compile from last bzr repo

[Eli Zaretskii]

> From: Bastien <bzg@altern.org>
> Date: Mon, 04 Apr 2011 11:46:59 +0200
> 
> I just checked out the bzr repo and cannot compile with this error:
> 
> In toplevel form:
> emacs-lisp/byte-opt.el:247:1:Error: Unknown upattern `(let env nil)'
> make[2]: *** [/home/guerry/install/bzr/emacs/build/lisp/emacs-lisp/byte-opt.elc] Erreur 1
> make[2]: quittant le répertoire « /home/guerry/install/bzr/emacs/build/lisp »
> make[1]: *** [bootstrap-emacs] Erreur 2
> make[1]: quittant le répertoire « /home/guerry/install/bzr/emacs/build/src »
> make: *** [src] Erreur 2

You need to "make bootstrap".  This is the result of lexbind merge,
AFAIK.

Re: Failed to compile from last bzr repo

[Deniz Dogan]

2011/4/4 Eli Zaretskii <eliz@gnu.org>:
>> From: Bastien <bzg@altern.org>
>> Date: Mon, 04 Apr 2011 11:46:59 +0200
>>
>> I just checked out the bzr repo and cannot compile with this error:
>>
>> In toplevel form:
>> emacs-lisp/byte-opt.el:247:1:Error: Unknown upattern `(let env nil)'
>> make[2]: *** [/home/guerry/install/bzr/emacs/build/lisp/emacs-lisp/byte-opt.elc] Erreur 1
>> make[2]: quittant le répertoire « /home/guerry/install/bzr/emacs/build/lisp »
>> make[1]: *** [bootstrap-emacs] Erreur 2
>> make[1]: quittant le répertoire « /home/guerry/install/bzr/emacs/build/src »
>> make: *** [src] Erreur 2
>
> You need to "make bootstrap".  This is the result of lexbind merge,
> AFAIK.
>

Sorry if this information can be found elsewhere but, in general, when
do you have to make bootstrap?

-- 
Deniz Dogan

Re: Failed to compile from last bzr repo

[Sean Sieger]

Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:

    Sorry if this information can be found elsewhere but, in general, when
    do you have to make bootstrap?

I do it every time I build Emacs; so often developers patiently asked,
`Does it fail with make bootstrap?' when I had reported a build failure.

Re: Failed to compile from last bzr repo

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> You need to "make bootstrap".  This is the result of lexbind merge,
> AFAIK.

That did it, thanks a lot Eli.

-- 
 Bastien

Re: Failed to compile from last bzr repo

[Stefan Monnier]

> Sorry if this information can be found elsewhere but, in general, when
> do you have to make bootstrap?

If there was a simple constructive answer to this, we'd do
it automatically.  But as of now, the best I can come up with is:
when "make" doesn't work but "make bootstrap" does; which probably
doesn't help you much.


        Stefan


PS: In your particular case, the issue is that cconv.el uses a new
feature in pcase.el, so removing pcase.elc and then "make" will help.
IIRC you'll bump into a few more problems after that, but removing
a few more .elc files (byte-opt, bytecomp, subr) and src/bootstrap
can get you over the hump.


        Stefan "who *very* rarely bootstraps because it takes ages on
                his machine"

Re: Failed to compile from last bzr repo

[Eli Zaretskii]

> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> Date: Mon, 4 Apr 2011 14:22:41 +0200
> Cc: Bastien <bzg@altern.org>, emacs-devel@gnu.org
> 
> > You need to "make bootstrap".  This is the result of lexbind merge,
> > AFAIK.
> >
> 
> Sorry if this information can be found elsewhere but, in general, when
> do you have to make bootstrap?

Like Stefan said, there's no simple recipe.

In general, if the build fails while compiling Lisp files or during
loadup, and removing a few *.elc files mentioned in the "Source file
FOO newer than byte-compiled file" messages around the point of
failure doesn't resolve that, it's a sign that a bootstrap is in
order.

Re: Failed to compile from last bzr repo

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Mon, 04 Apr 2011 08:38:38 -0400
> 
> Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:
> 
>     Sorry if this information can be found elsewhere but, in general, when
>     do you have to make bootstrap?
> 
> I do it every time I build Emacs

Unfortunately, bootstrap on Windows takes a very long time, so I try
to avoid bootstrapping as much as I can.

Re: Failed to compile from last bzr repo

[Juanma Barranquero]

On Mon, Apr 4, 2011 at 19:37, Eli Zaretskii <eliz@gnu.org> wrote:

> Unfortunately, bootstrap on Windows takes a very long time

In my setup it takes ~20 min. It is much longer in yours, or do you
consider 20 min a very long time?

    Juanma

Re: Failed to compile from last bzr repo

[Stefan Monnier]

>> Unfortunately, bootstrap on Windows takes a very long time
> In my setup it takes ~20 min. It is much longer in yours, or do you
> consider 20 min a very long time?

On one of my setups it takes about 4mins (8 dual core AMD chips help),
but that's not one I can use as easily as my fit-pc2 desktop where it
takes just a tiny bit loner (especially with -O0 and all assertions
enabled).  It takes long enough there that I don't even know how long
because I usually only do it when I can swap to some other long task.


        Stefan

Re: Failed to compile from last bzr repo

[Juanma Barranquero]

On Mon, Apr 4, 2011 at 23:51, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> On one of my setups it takes about 4mins (8 dual core AMD chips help),

Now I'm envy.

> takes just a tiny bit loner (especially with -O0 and all assertions
> enabled).

Because of it being slower during all the .el compilations, you mean?

I regularly build both -O2 --enable-checking and -O0 --enable-checking
and I haven't seen much difference, but now I'm curious.

    Juanma

Re: Failed to compile from last bzr repo

[Sean Sieger]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

    >> Unfortunately, bootstrap on Windows takes a very long time
    > In my setup it takes ~20 min. It is much longer in yours, or do you
    > consider 20 min a very long time?

    On one of my setups it takes about 4mins (8 dual core AMD chips help),
    but that's not one I can use as easily as my fit-pc2 desktop where it
    takes just a tiny bit loner (especially with -O0 and all assertions
    enabled).  It takes long enough there that I don't even know how long
    because I usually only do it when I can swap to some other long task.

:)  I've never timed the bootstrap; intuitively, I come back to the
build, check to see that it runs with a few idiosyncratic functions and
move on with make info and so on.  I just figure the possible waste of
time, let alone other's time and additionally building again (given not
bootstrapping in the first place) doesn't work for me.  I don't recall
my Unix build process (and rarely bootstrapping a second time after an
initial one) taking much less time ... I think I'm just always pleased
with the reward of a wonderful GNU Emacs (and come on, folks, I know
some of you jaded son-of-guns still experience some wonderment).  I'm in
NYC, I can get a pint of ice cream or a quart of milk in 5 minutes round
trip, building Emacs in what ever time it happens to be is Worth It.

Re: Failed to compile from last bzr repo

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 4 Apr 2011 23:19:33 +0200
> Cc: Sean Sieger <sean.sieger@gmail.com>, emacs-devel@gnu.org
> 
> On Mon, Apr 4, 2011 at 19:37, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Unfortunately, bootstrap on Windows takes a very long time
> 
> In my setup it takes ~20 min. It is much longer in yours, or do you
> consider 20 min a very long time?

The latter, of course.

Re: Failed to compile from last bzr repo

[Stefan Monnier]

>> takes just a tiny bit loner (especially with -O0 and all assertions
>> enabled).
> Because of it being slower during all the .el compilations, you mean?
> I regularly build both -O2 --enable-checking and -O0 --enable-checking
> and I haven't seen much difference, but now I'm curious.

I don't know, to tell you the truth: I always compile with -O0, unions,
and all assertions I can think of enabled.  And I tend to find it
significantly slower than the rare few times that I do a test
build with all default settings.  But I never bothered to measure it.


        Stefan

Re: Failed to compile from last bzr repo

[Sean Sieger]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

    >> takes just a tiny bit loner (especially with -O0 and all assertions
    >> enabled).
    > Because of it being slower during all the .el compilations, you mean?
    > I regularly build both -O2 --enable-checking and -O0 --enable-checking
    > and I haven't seen much difference, but now I'm curious.

    I don't know, to tell you the truth: I always compile with -O0, unions,
    and all assertions I can think of enabled.  And I tend to find it
    significantly slower than the rare few times that I do a test
    build with all default settings.  But I never bothered to measure it.

Where do you find the configure information that you and Juanma are
discussing?  I've poked around, but I haven't found anything beyond
configure --help.  The INSTALL files don't say, right?  The assertions,
CFLAGs and so on, where are they listed?

Re: Failed to compile from last bzr repo

[Sean Sieger]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

    >> takes just a tiny bit loner (especially with -O0 and all assertions
    >> enabled).
    > Because of it being slower during all the .el compilations, you mean?
    > I regularly build both -O2 --enable-checking and -O0 --enable-checking
    > and I haven't seen much difference, but now I'm curious.

    I don't know, to tell you the truth: I always compile with -O0, unions,
    and all assertions I can think of enabled.  And I tend to find it
    significantly slower than the rare few times that I do a test
    build with all default settings.  But I never bothered to measure it.


Where do you find the configure information that you and Juanma are
discussing?  I've poked around, but I haven't found anything beyond
configure --help.  The INSTALL files don't say, right?  The assertions,
CFLAGs and so on, where are they listed?

Re: Failed to compile from last bzr repo

[Juanma Barranquero]

On Tue, Apr 5, 2011 at 17:39, Sean Sieger <sean.sieger@gmail.com> wrote:

> Where do you find the configure information that you and Juanma are
> discussing?  I've poked around, but I haven't found anything beyond
> configure --help.  The INSTALL files don't say, right?  The assertions,
> CFLAGs and so on, where are they listed?

I don't understand the question.  configure --help lists
`--enable-checking', which already activates lots of assertions.

There are other checks you can enable, like GLYPH_DEBUG, FONT_DEBUG
and DEBUG_GCPRO, but you have to do it by hand. This is as easy as
passing "--cflags -DFONT_DEBUG" to configure, except in the case of
GLYPH_DEBUG, which must be set to 1. This is currently unsupported on
Windows (cmd.exe interprets "=" as a separator, so it doesn't grok
-DGLYPH_DEBUG=1). If you're interested you can change the makefiles
after running configure (I'd recommend writing a small perl script or
some such and running it after configure.bat).

Take a look at lisp.h for other options, like USE_LISP_UNION_TYPE.

Hope this helps,

    Juanma

Re: Failed to compile from last bzr repo

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 5 Apr 2011 18:36:38 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> There are other checks you can enable, like GLYPH_DEBUG, FONT_DEBUG
> and DEBUG_GCPRO, but you have to do it by hand. This is as easy as
> passing "--cflags -DFONT_DEBUG" to configure, except in the case of
> GLYPH_DEBUG, which must be set to 1. This is currently unsupported on
> Windows (cmd.exe interprets "=" as a separator, so it doesn't grok
> -DGLYPH_DEBUG=1).

Maybe we should do on nt/config.nt

 #ifdef GLYPH_DEBUG
 # undef GLYPH_DEBUG
 # define GLYPH_DEBUG 1
 #endif

Then a simple "--cflags -DGLYPH_DEBUG" option to configure will do.

WDYT?

Re: Failed to compile from last bzr repo

[Stefan Monnier]

> Where do you find the configure information that you and Juanma are
> discussing?

The old way: looking at the C code macros, I add some "-D<foo>" to my
CFLAGS and use a script to run make, which passes the extra flags
I want.


        Stefan

Re: Failed to compile from last bzr repo

[Juanma Barranquero]

On Tue, Apr 5, 2011 at 18:52, Eli Zaretskii <eliz@gnu.org> wrote:

> Maybe we should do on nt/config.nt
>
>  #ifdef GLYPH_DEBUG
>  # undef GLYPH_DEBUG
>  # define GLYPH_DEBUG 1
>  #endif
>
> Then a simple "--cflags -DGLYPH_DEBUG" option to configure will do.

Good idea, though in the long term we must find a way to pass -DX=Y to
configure.bat. Either having a separate --define option which grabs
two values, or by reading options from an environment variable, like
someone recently sugested.

    Juanma

Re: Failed to compile from last bzr repo

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 6 Apr 2011 00:45:46 +0200
> Cc: sean.sieger@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> >  #ifdef GLYPH_DEBUG
> >  # undef GLYPH_DEBUG
> >  # define GLYPH_DEBUG 1
> >  #endif
> >
> > Then a simple "--cflags -DGLYPH_DEBUG" option to configure will do.
> 
> Good idea, though in the long term we must find a way to pass -DX=Y to
> configure.bat. Either having a separate --define option which grabs
> two values, or by reading options from an environment variable, like
> someone recently sugested.

I think the above is much easier than any of the alternatives.  In
particular, setting an environment variable sounds both ugly and
dangerous to me (the risk of leaving it set is high).

Re: Failed to compile from last bzr repo

[Juanma Barranquero]

On Wed, Apr 6, 2011 at 05:01, Eli Zaretskii <eliz@gnu.org> wrote:

> I think the above is much easier than any of the alternatives.

Sure, and I agree with adding that change.

But this method does not work if the user wants to --cflag
-DSITELOAD_PURESIZE_EXTRA=100000

> In
> particular, setting an environment variable sounds both ugly and
> dangerous to me (the risk of leaving it set is high).

I don't like it either, but it's easier than trying to workaround the
=-is-a-separator issue.

    Juanma

Re: Failed to compile from last bzr repo

[Andy Moreton]

On Wed 06 Apr 2011, Juanma Barranquero wrote:

> On Wed, Apr 6, 2011 at 05:01, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> I think the above is much easier than any of the alternatives.
>
> Sure, and I agree with adding that change.
>
> But this method does not work if the user wants to --cflag
> -DSITELOAD_PURESIZE_EXTRA=100000
>
>> In
>> particular, setting an environment variable sounds both ugly and
>> dangerous to me (the risk of leaving it set is high).
>
> I don't like it either, but it's easier than trying to workaround the
> =-is-a-separator issue.
>
>     Juanma

Due to some changes made in the last day or so, the Win32 build no
longer bootstraps. There are two issues that need fixing up:

a) ATTRIBUTE_FORMAT() and ATTRIBUTE_FORMAT_PRINTF() are undefined.
b) careadlinkatcwd() and careadlinkat are undefined in src/sysdep.c

The missing macros in (a) can be worked around by adding a force-include
header file:

  cmd.exe /C "configure.bat ${args} --with-gcc --no-cygwin \
--cflags -I$(cygpath -wm ${srcdir}/nt) \
--cflags -include --cflags user_defines.h \
"

This forces inclusion of "nt/user_defines.h" which can then contain any
user defined macro definitions or workarounds. Incorporating something
like this into configure.bat would allow user defined macros while
avoiding the problems with quoting '='.

For MSVC based builds, I expect "--cflags /FI --cflags user_defines.h"
to work in a similar fashion.

    AndyM

Re: Failed to compile from last bzr repo

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Wed, 06 Apr 2011 13:57:58 +0100
> 
> Due to some changes made in the last day or so, the Win32 build no
> longer bootstraps.

Actually, it's due to revision 103841 committed just a couple of hours
ago.  I will fix it later today, if no one beats me to it.

Re: Failed to compile from last bzr repo

[Juanma Barranquero]

On Wed, Apr 6, 2011 at 15:32, Eli Zaretskii <eliz@gnu.org> wrote:

> Actually, it's due to revision 103841 committed just a couple of hours
> ago.  I will fix it later today, if no one beats me to it.

I've fixed lib/makefile.w32-in, so the only remaining issue seems to
be ATTRIBUTE_FORMAT_PRINTF.

Just defining it to nothing in nt/config.nt is enough to make the
compilation works. Is there anything more intelligent to do with it?

    Juanma

Re: Failed to compile from last bzr repo

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 6 Apr 2011 16:18:45 +0200
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> 
> I've fixed lib/makefile.w32-in

Thanks.  However, I'm going to redo some of that, sorry.  I don't
think we should call two non-trivial functions just to always return
NULL.

> so the only remaining issue seems to be ATTRIBUTE_FORMAT_PRINTF.
> 
> Just defining it to nothing in nt/config.nt is enough to make the
> compilation works. Is there anything more intelligent to do with it?

Yes, see configure.in.  I simply copied what it does to config.nt, so
it should be fixed now (revno 103847).

Re: Failed to compile from last bzr repo

[Eli Zaretskii]

> Date: Wed, 06 Apr 2011 18:47:41 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: andrewjmoreton@gmail.com, emacs-devel@gnu.org
> 
> > From: Juanma Barranquero <lekktu@gmail.com>
> > Date: Wed, 6 Apr 2011 16:18:45 +0200
> > Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> > 
> > I've fixed lib/makefile.w32-in
> 
> Thanks.  However, I'm going to redo some of that, sorry.

Done.

Re: Failed to compile from last bzr repo

[Juanma Barranquero]

On Wed, Apr 6, 2011 at 17:47, Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks.  However, I'm going to redo some of that, sorry.  I don't
> think we should call two non-trivial functions just to always return
> NULL.

Don't worry. I knew that you disliked the change (I followed the
discussion), but I wanted to leave the trunk in a mostly-buildable
state.

    Juanma