New build process?

New build process?

[Alan Mackenzie]

Hi, Emacs.

I think I'm a bit behind the wave here, but has the build process
changed in the last few months?  In particular, after doing a bzr
branch, I don't seem to have ./configure; merely configure.in.

I don't seem to be able to find instructions about this, and I haven't
found anything relevant and recent in the emacs-devel archive.  Help,
please!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New build process?

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hi, Emacs.
>
> I think I'm a bit behind the wave here, but has the build process
> changed in the last few months?  In particular, after doing a bzr
> branch, I don't seem to have ./configure; merely configure.in.
>
> I don't seem to be able to find instructions about this, and I haven't
> found anything relevant and recent in the emacs-devel archive.  Help,
> please!

INSTALL.BZR

-- 
David Kastrup

Re: New build process?

[David Reitter]

On Jul 26, 2011, at 2:47 PM, David Kastrup wrote:
>> 
>> I don't seem to be able to find instructions about this, and I haven't
>> found anything relevant and recent in the emacs-devel archive.  Help,
>> please!
> 
> INSTALL.BZR

Suggest changing the name of this file.  Not everybody gets the source code via Bazaar.  When these inconvenient changes happened, I got caught out like Alan Mackenzie, since I wouldn't think of reading this file.

Better yet, include a configure script that calls autogen.sh and then runs itself.  If people consider this an inconvenience w.r.t. the version control tool, then perhaps autogen.sh could generate configure.local instead.

As others have said here, people expect to be able to do ./configure; make install.

Re: New build process?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On 7/26/11 1:00 PM, David Reitter wrote:
> As others have said here, people expect to be able to do ./configure; make install.

Sure, but having to run autogen.sh on a project that's just been checked out of
version control is also very common in the free software world, and our actual
source tarballs do contain pre-built autoconf scripts.  The problem with a
self-replacing configure script is that, as you mentioned, it'd be hard to tell
bzr to version the placeholder script, but ignore the generated one; solving
this problem by using a nonstandard name for the generated `configure'  script
would be surprising.  I think our current approach is fine.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: New build process?

[Richard Stallman]

    Sure, but having to run autogen.sh on a project that's just been checked out of
    version control is also very common in the free software world, and our actual
    source tarballs do contain pre-built autoconf scripts.  The problem with a
    self-replacing configure script is that, as you mentioned, it'd be hard to tell
    bzr to version the placeholder script, but ignore the generated one; solving
    this problem by using a nonstandard name for the generated `configure'  script
    would be surprising.  I think our current approach is fine.

We could call the current configuration script `configure-internal'.
Then have a small `configure' script that checks whether the
`configure-internal' file exists and is up to date, and if not,
generates it.  Then it would run `configure-internal'.

This would DTRT in all cases, wouldn't it?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: New build process?

[Tim Cross]

On Wed, Jul 27, 2011 at 12:58 PM, Richard Stallman <rms@gnu.org> wrote:
>    Sure, but having to run autogen.sh on a project that's just been checked out of
>    version control is also very common in the free software world, and our actual
>    source tarballs do contain pre-built autoconf scripts.  The problem with a
>    self-replacing configure script is that, as you mentioned, it'd be hard to tell
>    bzr to version the placeholder script, but ignore the generated one; solving
>    this problem by using a nonstandard name for the generated `configure'  script
>    would be surprising.  I think our current approach is fine.
>
> We could call the current configuration script `configure-internal'.
> Then have a small `configure' script that checks whether the
> `configure-internal' file exists and is up to date, and if not,
> generates it.  Then it would run `configure-internal'.
>
> This would DTRT in all cases, wouldn't it?
>

Lets not over engineer it! As far back as I can remember, emacs
sources from the version control repository had an additional step
that had to be completed ini order to generate the  configure script.
Previously, you ran autoget and now you run ./auttogen.sh. Previously,
people would get into problems if their autoconf tools werre an older
version that supported by the current configs for emacs - the new
method now tests to make sure the build tools satisfy version
restrictions, which I think is also an improvement.

The real issue here is whether INSTALL.BZR is an appropriate name for
the information that alerts people that you need to take extra steps
when building form sources taken from the version control repository.
Perhaps we can come up with a better name - though I'm not sure what.
'build-from -bzr.txt may be too long and won't help those who get the
sources form git. I find it hard to judge as I knew about the change
after it was announced on this list and didn't have to 'find it' from
the doc files, but I can understand how you would miss INSTALL.BZR.

Tim

Re: New build process?

[Eli Zaretskii]

> Date: Wed, 27 Jul 2011 13:40:03 +1000
> From: Tim Cross <theophilusx@gmail.com>
> Cc: david.reitter@gmail.com, Daniel Colascione <dan.colascione@gmail.com>,
> 	emacs-devel@gnu.org
> 
> As far back as I can remember, emacs
> sources from the version control repository had an additional step
> that had to be completed ini order to generate the  configure script.

I guess your memory is either faulty or doesn't go back far enough.
Because configure was removed from the Emacs repository only 4 months
ago (on 2011-03-20, see the logs).

> The real issue here is whether INSTALL.BZR is an appropriate name for
> the information that alerts people that you need to take extra steps
> when building form sources taken from the version control repository.

We had INSTALL.CVS when the VC was CVS, and I don't remember any
complaints.

Re: New build process?

[Tim Cross]

On Wed, Jul 27, 2011 at 3:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 27 Jul 2011 13:40:03 +1000
>> From: Tim Cross <theophilusx@gmail.com>
>> Cc: david.reitter@gmail.com, Daniel Colascione <dan.colascione@gmail.com>,
>>       emacs-devel@gnu.org
>>
>> As far back as I can remember, emacs
>> sources from the version control repository had an additional step
>> that had to be completed ini order to generate the  configure script.
>
> I guess your memory is either faulty or doesn't go back far enough.
> Because configure was removed from the Emacs repository only 4 months
> ago (on 2011-03-20, see the logs).
>

OK,  sorry, my error - must be confused with other projects. As has
been pointed out by others, the need to run autocont or some other
command to generate the config file is common when working from
sources directly taken from a revision control file.

>> The real issue here is whether INSTALL.BZR is an appropriate name for
>> the information that alerts people that you need to take extra steps
>> when building form sources taken from the version control repository.
>
> We had INSTALL.CVS when the VC was CVS, and I don't remember any
> complaints.
>

I thought that was what it use to be called. Partly what made me think
we had to generate the config script -  thinking again, it probably
only contained instructions relating to make bootstrap (which I don't
*think* you require for tar balls?) and some other platform specific
stuff.

Still, my main pint is I don't think we should get too carried away
trying to automate all of this. It is a common requirement and while
some may have been caught out, it is something you should expect when
working this close to the development layer. Efforts were made to
communicate the changes on this list (by you IIRC Eli) and there is
information in the INSTALL.BZR file. My objection with trying to
automate or eliminate this simple step is that the solution can often
be worse than the problem and adds just another point of potential
failure in a step which is already simple and straight-forward (once
you know about it!). However, if we can rename the file or make
another copy of the instructions under a name which the majority feel
is more likely to be noticed, great - all for that.

Tim

Re: New build process?

[Peter Münster]

On Wed, Jul 27 2011, Tim Cross wrote:

> Still, my main pint is I don't think we should get too carried away
> trying to automate all of this. It is a common requirement and while
> some may have been caught out, it is something you should expect when
> working this close to the development layer. Efforts were made to
> communicate the changes on this list (by you IIRC Eli) and there is
> information in the INSTALL.BZR file. My objection with trying to
> automate or eliminate this simple step is that the solution can often
> be worse than the problem and adds just another point of potential
> failure in a step which is already simple and straight-forward (once
> you know about it!).

+1


> However, if we can rename the file or make
> another copy of the instructions under a name which the majority feel
> is more likely to be noticed, great - all for that.

I don't see a big problem with the file name, but eventually you could
merge its content into INSTALL and then remove INSTALL.BZR.

-- 
           Peter

Re: New build process?

[Tim Cross]

On Wed, Jul 27, 2011 at 6:25 PM, Peter Münster <pmlists@free.fr> wrote:
> On Wed, Jul 27 2011, Tim Cross wrote:
>
>> Still, my main pint is I don't think we should get too carried away
>> trying to automate all of this. It is a common requirement and while
>> some may have been caught out, it is something you should expect when
>> working this close to the development layer. Efforts were made to
>> communicate the changes on this list (by you IIRC Eli) and there is
>> information in the INSTALL.BZR file. My objection with trying to
>> automate or eliminate this simple step is that the solution can often
>> be worse than the problem and adds just another point of potential
>> failure in a step which is already simple and straight-forward (once
>> you know about it!).
>
> +1
>
>
>> However, if we can rename the file or make
>> another copy of the instructions under a name which the majority feel
>> is more likely to be noticed, great - all for that.
>
> I don't see a big problem with the file name, but eventually you could
> merge its content into INSTALL and then remove INSTALL.BZR.
>

Except i don't believe you need to do this step when installing from a
tar ball - the configure script is usually provided. Therefore,
putting the instructions in the same file could confuse those building
from official non-evelopment releases (I'm assuming thats why they are
separated into two files now).

As you say, it not a big problem and I think its a communication issue
rather than a technical one and requires (possibly) requires a
communication fix rather than a technical one.

Tim

Re: New build process?

[Peter Münster]

On Wed, Jul 27 2011, Tim Cross wrote:

>> I don't see a big problem with the file name, but eventually you could
>> merge its content into INSTALL and then remove INSTALL.BZR.
>
> Except i don't believe you need to do this step when installing from a
> tar ball - the configure script is usually provided. Therefore,
> putting the instructions in the same file could confuse those building
> from official non-evelopment releases (I'm assuming thats why they are
> separated into two files now).

Of course, when I say "merge", I mean something like

    "If you install from bzr/git, please read section x.y for
     additional steps."

somewhere in the beginning. Or you keep INSTALL.BZR and refer to it in
INSTALL.


> As you say, it not a big problem and I think its a communication issue
> rather than a technical one and requires (possibly) requires a
> communication fix rather than a technical one.

Indeed. The only issue is, that someone does not take the effort to open
INSTALL.BZR ... ;-)

-- 
           Peter

Re: New build process?

[David Kastrup]

pmlists@free.fr (Peter Münster) writes:

> On Wed, Jul 27 2011, Tim Cross wrote:
>
>> Still, my main pint is I don't think we should get too carried away
>> trying to automate all of this. It is a common requirement and while
>> some may have been caught out, it is something you should expect when
>> working this close to the development layer. Efforts were made to
>> communicate the changes on this list (by you IIRC Eli) and there is
>> information in the INSTALL.BZR file. My objection with trying to
>> automate or eliminate this simple step is that the solution can often
>> be worse than the problem and adds just another point of potential
>> failure in a step which is already simple and straight-forward (once
>> you know about it!).
>
> +1
>
>
>> However, if we can rename the file or make
>> another copy of the instructions under a name which the majority feel
>> is more likely to be noticed, great - all for that.
>
> I don't see a big problem with the file name, but eventually you could
> merge its content into INSTALL and then remove INSTALL.BZR.

INSTALL are the instructions for a user installing from a tarball, so
they should likely not be overly complicated.  It does not harm to put a
sentence referring to INSTALL.BZR in, but INSTALL.BZR does not actually
need to be in a tarball.

I actually have a project where INSTALL is autogenerated from something
like doc/install.texi, so there is not even an INSTALL file in the
repository.  It is, naturally, in the tarballs.

I think we nowadays distribute INSTALL.CVS along in the tarballs, though
at one time we didn't.

-- 
David Kastrup

Re: New build process?

[Eli Zaretskii]

> From: pmlists@free.fr (Peter Münster)
> Date: Wed, 27 Jul 2011 10:25:33 +0200
> 
> I don't see a big problem with the file name, but eventually you could
> merge its content into INSTALL and then remove INSTALL.BZR.

INSTALL is for installing the release tarball, so it should not have
anything about bzr etc.  It will confuse users.

Re: New build process?

[Eli Zaretskii]

> Date: Wed, 27 Jul 2011 17:58:39 +1000
> From: Tim Cross <theophilusx@gmail.com>
> Cc: rms@gnu.org, david.reitter@gmail.com, dan.colascione@gmail.com, 
> 	emacs-devel@gnu.org
> 
> Still, my main pint is I don't think we should get too carried away
> trying to automate all of this. It is a common requirement and while
> some may have been caught out, it is something you should expect when
> working this close to the development layer.

I'm actually with Richard on this one.  I think the need to install,
update, and use any additional commands before "./configure; make" is
a nuisance whose justification is questionable at best.  It's just
that I gave up on talking people into catering to us dinosaurs whose
paradise was lost, and Richard is still trying, because he's a better
man than I am.

> Efforts were made to communicate the changes on this list (by you
> IIRC Eli)

Actually, I think it was Glenn, not me.

> My objection with trying to automate or eliminate this simple step
> is that the solution can often be worse than the problem

The solution is, quite obviously, to have the configure script in the
repo.  No, don't answer that.

Re: New build process?

[Tim Cross]

On Wed, Jul 27, 2011 at 8:03 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 27 Jul 2011 17:58:39 +1000
>> From: Tim Cross <theophilusx@gmail.com>
>> Cc: rms@gnu.org, david.reitter@gmail.com, dan.colascione@gmail.com,
>>       emacs-devel@gnu.org
>>
>> Still, my main pint is I don't think we should get too carried away
>> trying to automate all of this. It is a common requirement and while
>> some may have been caught out, it is something you should expect when
>> working this close to the development layer.
>
> I'm actually with Richard on this one.  I think the need to install,
> update, and use any additional commands before "./configure; make" is
> a nuisance whose justification is questionable at best.  It's just
> that I gave up on talking people into catering to us dinosaurs whose
> paradise was lost, and Richard is still trying, because he's a better
> man than I am.
>

If you believe you can do it and make it solid (which I expect you
can), then go for it. I personally don't think it is necessary as we
are talking about users who are choosing to interact at a low
development level, which IMO is a moving target subject to change and
instability. We should not set the bar too high here - put our efforts
into improving emacs and not into improving the build process for
those who chose to interact at this level.

Yes, I guess I would be considered a dinosaur and possibly not even a
very bright one. However, despite some improvements, many of the more
modern approaches don't seem better. Ironically, I find many of them
dis-empowering as more and more of the process becomes hidden behind
ever increasing complexity, all in the name of usability. The problem
is, as soon as it breaks, we are lost!

Richard has certainly achieved some impressive things and I'm sure his
name will be remembered long after mine is forgotten (which will
likely be in about 10 minutes from now). Whether he is a better man
than any of the rest of us is unknown. While I may not agree with the
IT cloud, my mind is sometimes in the ideological cloud and at these
times, I tend to dream that we are all of equal worth and greatness.


>> Efforts were made to communicate the changes on this list (by you
>> IIRC Eli)
>

> Actually, I think it was Glenn, not me.
>

Shzz - pretty poor recolleciton stats for me then - two fails out of
two attempts. Really need to consider a better quality of red wine!

>> My objection with trying to automate or eliminate this simple step
>> is that the solution can often be worse than the problem
>
> The solution is, quite obviously, to have the configure script in the
> repo.  No, don't answer that.
>

Wouldn't dream of it :)

Tim

Re: New build process?

[Lennart Borgman]

On Wed, Jul 27, 2011 at 15:11, Tim Cross <theophilusx@gmail.com> wrote:
>>
>> I'm actually with Richard on this one.  I think the need to install,
>> update, and use any additional commands before "./configure; make" is
>> a nuisance whose justification is questionable at best.  It's just
>> that I gave up on talking people into catering to us dinosaurs whose
>> paradise was lost, and Richard is still trying, because he's a better
>> man than I am.
>>
>
> If you believe you can do it and make it solid (which I expect you
> can), then go for it. I personally don't think it is necessary as we
> are talking about users who are choosing to interact at a low
> development level, which IMO is a moving target subject to change and
> instability. We should not set the bar too high here - put our efforts
> into improving emacs and not into improving the build process for
> those who chose to interact at this level.
>
> Yes, I guess I would be considered a dinosaur and possibly not even a

Dear dinosaur, can't you believe making the build process simple saves
a lot of time for many developers? And then it is possible for them to
improve Emacs even more. (Everything that makes Emacs more stable may
save a lot of time.)

Re: New build process?

[David Kastrup]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Wed, Jul 27, 2011 at 15:11, Tim Cross <theophilusx@gmail.com> wrote:
>>>
>>> I'm actually with Richard on this one.  I think the need to install,
>>> update, and use any additional commands before "./configure; make" is
>>> a nuisance whose justification is questionable at best.  It's just
>>> that I gave up on talking people into catering to us dinosaurs whose
>>> paradise was lost, and Richard is still trying, because he's a better
>>> man than I am.
>>>
>>
>> If you believe you can do it and make it solid (which I expect you
>> can), then go for it. I personally don't think it is necessary as we
>> are talking about users who are choosing to interact at a low
>> development level, which IMO is a moving target subject to change and
>> instability. We should not set the bar too high here - put our efforts
>> into improving emacs and not into improving the build process for
>> those who chose to interact at this level.
>>
>> Yes, I guess I would be considered a dinosaur and possibly not even a
>
> Dear dinosaur, can't you believe making the build process simple saves
> a lot of time for many developers?

The build process _is_ simple.  The question is more about it being
discoverable.  Adding two sentences to INSTALL in the line of

    These are the installation instructions for compiling Emacs from a
    distribution tarball.  If you are working from a Bazaar checkout,
    please refer to INSTALL.BZR.

should be enough.

-- 
David Kastrup

Re: New build process?

[David De La Harpe Golden]

On 27/07/11 14:56, David Kastrup wrote:


> The build process _is_ simple.  The question is more about it being
> discoverable.  Adding two sentences to INSTALL in the line of
>
>      These are the installation instructions for compiling Emacs from a
>      distribution tarball.  If you are working from a Bazaar checkout,
>      please refer to INSTALL.BZR.
>

Note INSTALL does already say, right near the top:

"""
For information about building from a Bazaar checkout
(rather than a release), also read the file INSTALL.BZR.
"""

Now, there's a small technical issue that "checkout" means something (or 
two things) specific in bzr jargon - heavyweight checkout / bound branch 
or lightweight checkout, so AFAIUI it's perfectly feasible to build 
emacs from a local bzr branch that isn't a checkout in bzr terms, but 
that's probably overly pedantic.

People who get their emacs sources from some unofficial git repository 
or something might conceivably think "oh, but I didn't use bzr or a 
release", but I don't think emacs can be responsible for such things - 
bzr is the current official VCS, for better or worse.

Re: New build process?

[David Kastrup]

David De La Harpe Golden <david@harpegolden.net> writes:

> On 27/07/11 14:56, David Kastrup wrote:
>
>
>> The build process _is_ simple.  The question is more about it being
>> discoverable.  Adding two sentences to INSTALL in the line of
>>
>>      These are the installation instructions for compiling Emacs from a
>>      distribution tarball.  If you are working from a Bazaar checkout,
>>      please refer to INSTALL.BZR.
>>
>
> Note INSTALL does already say, right near the top:
>
> """
> For information about building from a Bazaar checkout
> (rather than a release), also read the file INSTALL.BZR.
> """

I honestly did not look.  So we can chalk this discussion off as "Alan's
fault" and find something else to worry about.

-- 
David Kastrup

Re: New build process?

[Alan Mackenzie]

Hi, David.

On Thu, Jul 28, 2011 at 02:46:40PM +0200, David Kastrup wrote:
> David De La Harpe Golden <david@harpegolden.net> writes:

> > On 27/07/11 14:56, David Kastrup wrote:


> >> The build process _is_ simple.  The question is more about it being
> >> discoverable.  Adding two sentences to INSTALL in the line of

> >>      These are the installation instructions for compiling Emacs from a
> >>      distribution tarball.  If you are working from a Bazaar checkout,
> >>      please refer to INSTALL.BZR.


> > Note INSTALL does already say, right near the top:

> > """
> > For information about building from a Bazaar checkout
> > (rather than a release), also read the file INSTALL.BZR.
> > """

> I honestly did not look.  So we can chalk this discussion off as "Alan's
> fault" and find something else to worry about.

I agree.  I'm a bit despondent that my request triggered off such a
depressingly long thread.  I would have been quite happy with Your first
reply (for which many thanks).

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New build process?

[Tim Cross]

On Wed, Jul 27, 2011 at 11:31 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Wed, Jul 27, 2011 at 15:11, Tim Cross <theophilusx@gmail.com> wrote:
>>>
>>> I'm actually with Richard on this one.  I think the need to install,
>>> update, and use any additional commands before "./configure; make" is
>>> a nuisance whose justification is questionable at best.  It's just
>>> that I gave up on talking people into catering to us dinosaurs whose
>>> paradise was lost, and Richard is still trying, because he's a better
>>> man than I am.
>>>
>>
>> If you believe you can do it and make it solid (which I expect you
>> can), then go for it. I personally don't think it is necessary as we
>> are talking about users who are choosing to interact at a low
>> development level, which IMO is a moving target subject to change and
>> instability. We should not set the bar too high here - put our efforts
>> into improving emacs and not into improving the build process for
>> those who chose to interact at this level.
>>
>> Yes, I guess I would be considered a dinosaur and possibly not even a
>
> Dear dinosaur, can't you believe making the build process simple saves
> a lot of time for many developers? And then it is possible for them to
> improve Emacs even more. (Everything that makes Emacs more stable may
> save a lot of time.)
>

Come ojn - this is really getting out of scale.

Currently, to build from bzr you need to run ./autogen.sh to generate
the configure script. One simple additional command. Its not
complicated, its not hard - one *SIMPLE* step.

If we were talking about something that was complicated or a lot of
people had trouble with, I would understand. In reality, this thread
was really kicked off simply because the status quo had changed very
slightly and someone was frustrated that this was not obvious to them
and caused them to waste time. The reality is that if you are going to
choose to work at this level, you are likely to see change and it is
even likely to be unstable change from time to time.

Get over it, move on, there is nothing to see here!

Tim

Re: New build process?

[Richard Stallman]

    I'm actually with Richard on this one.  I think the need to install,
    update, and use any additional commands before "./configure; make" is
    a nuisance whose justification is questionable at best.  It's just
    that I gave up on talking people into catering to us dinosaurs whose
    paradise was lost, and Richard is still trying, because he's a better
    man than I am.

It ought to be a simple job for someone who is fully familiar with the
current build mechanism.  The hardest part is to change the name of
the automatically-generated configuration file, because that change
may need to be made in a few places.  Once that's done, I'd expect the
new configure file to be less than 20 lines.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: New build process?

[Eli Zaretskii]

> Date: Wed, 27 Jul 2011 12:14:45 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: theophilusx@gmail.com, david.reitter@gmail.com,
> 	dan.colascione@gmail.com, emacs-devel@gnu.org
> 
> It ought to be a simple job for someone who is fully familiar with the
> current build mechanism.

I won't even think doing that, because most developers and other
maintainers think the current arrangement is the best of all worlds.

Re: New build process?

[Paul Eggert]

On 07/27/11 03:03, Eli Zaretskii wrote:
 
> ... the need to install,
> update, and use any additional commands before "./configure; make" is
> a nuisance whose justification is questionable at best.  It's just
> that I gave up on talking people into catering to us dinosaurs

The *real* dinosaurs just type "make".  The "./configure; make"
business is a relative latecomer.

It'd be nice if one could just type "make".

To help move in that direction, I installed the following patch.
It assumes GNU Make, but that's a reasonable assumption these
days for developers.  Developers who insist on using non-GNU "make"
can use "./autogen.sh; ./configure; make" as before.

If there are any problems with this, please feel free to back it out
or improve it.

* GNUmakefile: New file.
This is for convenience, so that one can run GNU make in an
unconfigured source tree, and get a default build.
=== added file 'GNUmakefile'
--- GNUmakefile	1970-01-01 00:00:00 +0000
+++ GNUmakefile	2011-07-27 20:22:50 +0000
@@ -0,0 +1,77 @@
+# Build Emacs from a fresh tarball or version-control checkout.
+
+# Copyright 2011 Free Software Foundation, Inc.
+#
+# This file is part of GNU Emacs.
+#
+# GNU Emacs is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# GNU Emacs is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
+#
+# written by Paul Eggert
+
+
+# This GNUmakefile is for GNU Make.  It is for convenience, so that
+# one can run 'make' in an unconfigured source tree.  In such a tree,
+# this file causes GNU Make to first create a standard configuration
+# with the default options, and then reinvokes itself on the
+# newly-built Makefile.  If the source tree is already configured,
+# this file defers to the existing Makefile.
+
+# If you are using a non-GNU 'make', or if you want non-default build
+# options, or if you want to build in an out-of-source tree, please
+# run "configure" by hand.  But run autogen.sh first, if the source
+# was checked out directly from the repository.
+
+
+# If a Makefile already exists, just use it.
+
+ifeq ($(wildcard Makefile),Makefile)
+include Makefile
+else
+
+# If cleaning and Makefile does not exist, don't bother creating it.
+# The source tree is already clean, or is in a weird state that
+# requires expert attention.
+
+ifeq ($(filter-out %clean,$(or $(MAKECMDGOALS),default)),)
+
+$(MAKECMDGOALS):
+	@echo >&2 'No Makefile; skipping $@.'
+
+else
+
+# No Makefile, and not cleaning.
+# If 'configure' does not exist, Emacs must have been checked
+# out directly from the repository; run ./autogen.sh.
+# Once 'configure' exists, run it.
+# Finally, run the actual 'make'.
+
+default $(filter-out configure Makefile,$(MAKECMDGOALS)): Makefile
+	$(MAKE) -f Makefile $(MAKECMDGOALS)
+# Execute in sequence, so that multiple user goals don't conflict.
+.NOTPARALLEL:
+
+configure:
+	@echo >&2 'There seems to be no "configure" file in this directory.'
+	@echo >&2 'Running ./autogen.sh || autogen/copy_autogen ...'
+	./autogen.sh || autogen/copy_autogen
+	@echo >&2 '"configure" file built.'
+
+Makefile: configure
+	@echo >&2 'There seems to be no Makefile in this directory.'
+	@echo >&2 'Running ./configure ...'
+	./configure
+	@echo >&2 'Makefile built.'
+
+endif
+endif

Re: New build process?

[Eli Zaretskii]

> Date: Wed, 27 Jul 2011 13:27:31 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Tim Cross <theophilusx@gmail.com>, david.reitter@gmail.com, 
>  dan.colascione@gmail.com, rms@gnu.org, emacs-devel@gnu.org
> 
> To help move in that direction, I installed the following patch.
> It assumes GNU Make, but that's a reasonable assumption these
> days for developers.  Developers who insist on using non-GNU "make"
> can use "./autogen.sh; ./configure; make" as before.
> 
> If there are any problems with this, please feel free to back it out
> or improve it.

It works, at least for me, thanks.  It also indirectly solves
bug#9106, so it can be closed now.

(There will be a need for a minor change in the DOS config.bat script,
to avoid running GNUMakefile on DOS, but that's trivial.)

Re: New build process?

[Richard Stallman]

    The *real* dinosaurs just type "make".  The "./configure; make"
    business is a relative latecomer.

The GNU configure spec was developed in the mid 80s,
rather early in the development of GNU Emacs.
In other words, all us dinosaurs are used to it.
I think you're talking about trilobites.

This GNUmakefile is a good hack.  However, it would be good
to also do the one I suggested, for the sake of people who
know and use the GNU configure spec.  That should be even easier
now, since the code from GNUmakefile can be reused.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: New build process?

[Andreas Schwab]

Tim Cross <theophilusx@gmail.com> writes:

> autoget

What's that?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New build process?

[Tim Cross]

On Wed, Jul 27, 2011 at 5:51 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> autoget
>
> What's that?
>

a typo - their quite common you know. Context usually helps to
recognize them. In this case, autogen is probably the most likely
candidate :)

Re: New build process?

[Andreas Schwab]

Tim Cross <theophilusx@gmail.com> writes:

> a typo - their quite common you know. Context usually helps to
> recognize them. In this case, autogen is probably the most likely
> candidate :)

What has autogen to do with emacs?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New build process?

[Tim Cross]

On Wed, Jul 27, 2011 at 6:07 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> a typo - their quite common you know. Context usually helps to
>> recognize them. In this case, autogen is probably the most likely
>> candidate :)
>
> What has autogen to do with emacs?
>

autogen.sh then if you must be pedantic about it, but I would have
thought that was quite obvious to anyone who has built from bzr
sources in the last 4 months.

Re: New build process?

[Andreas Schwab]

Tim Cross <theophilusx@gmail.com> writes:

> On Wed, Jul 27, 2011 at 6:07 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> a typo - their quite common you know. Context usually helps to
>>> recognize them. In this case, autogen is probably the most likely
>>> candidate :)
>>
>> What has autogen to do with emacs?
>>
>
> autogen.sh then if you must be pedantic about it,

You wrote: "Previously, you ran autoget and now you run ./autogen.sh"
(with typo fixed), now you claim: "Previously, you ran autogen.sh and
now you run ./autogen.sh".

That does not make sense to me.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New build process?

[Tim Cross]

On Wed, Jul 27, 2011 at 6:22 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> On Wed, Jul 27, 2011 at 6:07 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>> Tim Cross <theophilusx@gmail.com> writes:
>>>
>>>> a typo - their quite common you know. Context usually helps to
>>>> recognize them. In this case, autogen is probably the most likely
>>>> candidate :)
>>>
>>> What has autogen to do with emacs?
>>>
>>
>> autogen.sh then if you must be pedantic about it,
>
> You wrote: "Previously, you ran autoget and now you run ./autogen.sh"
> (with typo fixed), now you claim: "Previously, you ran autogen.sh and
> now you run ./autogen.sh".
>
> That does not make sense to me.

You left no context before, so I had no idea what you were getting at.
As you will see in my reply to Eli, I was mistaken in my recollection.
However, now you have provided the context rather than just a word, I
can say that autoget should have been autoconf.

Tim

Re: New build process?

[David Kastrup]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> On Wed, Jul 27, 2011 at 6:07 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>> Tim Cross <theophilusx@gmail.com> writes:
>>>
>>>> a typo - their quite common you know. Context usually helps to
>>>> recognize them. In this case, autogen is probably the most likely
>>>> candidate :)
>>>
>>> What has autogen to do with emacs?
>>>
>>
>> autogen.sh then if you must be pedantic about it,
>
> You wrote: "Previously, you ran autoget and now you run ./autogen.sh"
> (with typo fixed), now you claim: "Previously, you ran autogen.sh and
> now you run ./autogen.sh".
>
> That does not make sense to me.

And it is not what he has written at all.  Make it a habit to use copy
and paste when putting quote marks around something which you attribute
to a different source.

-- 
David Kastrup

Re: New build process?

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> On Wed, Jul 27, 2011 at 6:07 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>>> Tim Cross <theophilusx@gmail.com> writes:
>>>>
>>>>> a typo - their quite common you know. Context usually helps to
>>>>> recognize them. In this case, autogen is probably the most likely
>>>>> candidate :)
>>>>
>>>> What has autogen to do with emacs?
>>>>
>>>
>>> autogen.sh then if you must be pedantic about it,
>>
>> You wrote: "Previously, you ran autoget and now you run ./autogen.sh"
>> (with typo fixed), now you claim: "Previously, you ran autogen.sh and
>> now you run ./autogen.sh".
>>
>> That does not make sense to me.
>
> And it is not what he has written at all.

In which way does it differ?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New build process?

[David Kastrup]

Andreas Schwab <schwab@linux-m68k.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>
>>> Tim Cross <theophilusx@gmail.com> writes:
>>>
>>>> On Wed, Jul 27, 2011 at 6:07 PM, Andreas Schwab
>>>> <schwab@linux-m68k.org> wrote:
>>>>> Tim Cross <theophilusx@gmail.com> writes:
>>>>>
>>>>>> a typo - their quite common you know. Context usually helps to
>>>>>> recognize them. In this case, autogen is probably the most likely
>>>>>> candidate :)
>>>>>
>>>>> What has autogen to do with emacs?
>>>>>
>>>>
>>>> autogen.sh then if you must be pedantic about it,
>>>
>>> You wrote: "Previously, you ran autoget and now you run ./autogen.sh"
>>> (with typo fixed), now you claim: "Previously, you ran autogen.sh and
>>> now you run ./autogen.sh".
>>>
>>> That does not make sense to me.
>>
>> And it is not what he has written at all.
>
> In which way does it differ?

I fail to see how I could answer this more authoritatively than the
original mail.  It is not like it has magically vanished from the
archives, even if you managed to delete your personal copy.

-- 
David Kastrup

Re: New build process?

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>>
>>>> Tim Cross <theophilusx@gmail.com> writes:
>>>>
>>>>> On Wed, Jul 27, 2011 at 6:07 PM, Andreas Schwab
>>>>> <schwab@linux-m68k.org> wrote:
>>>>>> Tim Cross <theophilusx@gmail.com> writes:
>>>>>>
>>>>>>> a typo - their quite common you know. Context usually helps to
>>>>>>> recognize them. In this case, autogen is probably the most likely
>>>>>>> candidate :)
>>>>>>
>>>>>> What has autogen to do with emacs?
>>>>>>
>>>>>
>>>>> autogen.sh then if you must be pedantic about it,
>>>>
>>>> You wrote: "Previously, you ran autoget and now you run ./autogen.sh"
>>>> (with typo fixed), now you claim: "Previously, you ran autogen.sh and
>>>> now you run ./autogen.sh".
>>>>
>>>> That does not make sense to me.
>>>
>>> And it is not what he has written at all.
>>
>> In which way does it differ?
>
> I fail to see how I could answer this more authoritatively than the
> original mail. 

So why are you claiming there is a difference?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New build process?

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> On Jul 26, 2011, at 2:47 PM, David Kastrup wrote:
>>> 
>>> I don't seem to be able to find instructions about this, and I haven't
>>> found anything relevant and recent in the emacs-devel archive.  Help,
>>> please!
>> 
>> INSTALL.BZR
>
> Suggest changing the name of this file.  Not everybody gets the source
> code via Bazaar.  When these inconvenient changes happened, I got
> caught out like Alan Mackenzie, since I wouldn't think of reading this
> file.
>
> Better yet, include a configure script that calls autogen.sh and then
> runs itself.  If people consider this an inconvenience w.r.t. the
> version control tool, then perhaps autogen.sh could generate
> configure.local instead.
>
> As others have said here, people expect to be able to do ./configure;
> make install.

"people" get a tarball, and then this works perfectly fine and is
usually described in INSTALL.  When working from a version control
system, it is the rule rather than the exception that generated files
_including_ ./configure are _not_ checked into the version control
system, and that there is a separate INSTALL.CVS file or similar.  The
"usual way" for installing from a tarball is "./configure && make
install", and the "usual way" for installing from a version control
system checkout is "./autogen.sh && ./configure && make install".

It is an unreasonable expectation that ./configure is checked into the
version control system if it is a generated file and not source code.
It has been this way for a long time in the Emacs source tree, and has
been a source for trouble for a long time.  And obviously it has lead to
bad expectations as well.

-- 
David Kastrup

Re: New build process?

[Alan Mackenzie]

Hi, David.

On Tue, Jul 26, 2011 at 08:47:17PM +0200, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hi, Emacs.

> > I think I'm a bit behind the wave here, but has the build process
> > changed in the last few months?  In particular, after doing a bzr
> > branch, I don't seem to have ./configure; merely configure.in.

> > I don't seem to be able to find instructions about this, and I haven't
> > found anything relevant and recent in the emacs-devel archive.  Help,
> > please!

> INSTALL.BZR

Thanks for that.  Somehow, looking at the name, I thought that file was
to do with getting BZR installed, not getting Emacs installed.  ;-(

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New build process?

[Thien-Thi Nguyen]

() Alan Mackenzie <acm@muc.de>
() Tue, 26 Jul 2011 22:10:52 +0000

   Thanks for that.  Somehow, looking at the name, I thought that file was
   to do with getting BZR installed, not getting Emacs installed.  ;-(

How about renaming the file to HACKING?  That's fairly standard.
Put it in Org mode, add bug report tips and bzr coping links, etc...