From: Tim Cross <theophilusx@gmail.com>
To: rms@gnu.org
Cc: david.reitter@gmail.com,
Daniel Colascione <dan.colascione@gmail.com>,
emacs-devel@gnu.org
Subject: Re: New build process?
Date: Wed, 27 Jul 2011 13:40:03 +1000 [thread overview]
Message-ID: <CAC=50j9Of-N3uvaw3O86WEuk_PZDL1=40CLiiAqVGxe=XJeHrA@mail.gmail.com> (raw)
In-Reply-To: <E1QluJt-0008SP-RQ@fencepost.gnu.org>
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
next prev parent reply other threads:[~2011-07-27 3:40 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-26 18:42 New build process? Alan Mackenzie
2011-07-26 18:47 ` David Kastrup
2011-07-26 20:00 ` David Reitter
2011-07-26 20:16 ` Daniel Colascione
2011-07-27 2:58 ` Richard Stallman
2011-07-27 3:40 ` Tim Cross [this message]
2011-07-27 5:08 ` Eli Zaretskii
2011-07-27 7:58 ` Tim Cross
2011-07-27 8:25 ` Peter Münster
2011-07-27 8:48 ` Tim Cross
2011-07-27 9:43 ` Peter Münster
2011-07-27 8:51 ` David Kastrup
2011-07-27 10:05 ` Eli Zaretskii
2011-07-27 10:03 ` Eli Zaretskii
2011-07-27 13:11 ` Tim Cross
2011-07-27 13:31 ` Lennart Borgman
2011-07-27 13:56 ` David Kastrup
2011-07-28 12:37 ` David De La Harpe Golden
2011-07-28 12:46 ` David Kastrup
2011-07-29 12:36 ` Alan Mackenzie
2011-07-27 14:58 ` Tim Cross
2011-07-27 16:14 ` Richard Stallman
2011-07-27 16:25 ` Eli Zaretskii
2011-07-27 20:27 ` Paul Eggert
2011-07-28 10:06 ` Eli Zaretskii
2011-07-28 10:15 ` bug#9106: " Paul Eggert
2011-07-28 16:45 ` Richard Stallman
2011-07-27 7:51 ` Andreas Schwab
2011-07-27 8:02 ` Tim Cross
2011-07-27 8:07 ` Andreas Schwab
2011-07-27 8:13 ` Tim Cross
2011-07-27 8:22 ` Andreas Schwab
2011-07-27 8:31 ` Tim Cross
2011-07-27 8:54 ` David Kastrup
2011-07-27 9:01 ` Andreas Schwab
2011-07-27 9:15 ` David Kastrup
2011-07-27 9:41 ` Andreas Schwab
2011-07-26 20:24 ` David Kastrup
2011-07-26 22:10 ` Alan Mackenzie
2011-07-27 12:15 ` Thien-Thi Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC=50j9Of-N3uvaw3O86WEuk_PZDL1=40CLiiAqVGxe=XJeHrA@mail.gmail.com' \
--to=theophilusx@gmail.com \
--cc=dan.colascione@gmail.com \
--cc=david.reitter@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.