From: Glenn Morris <rgm@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 25359@debbugs.gnu.org
Subject: bug#25359: autoreconf no longer suffices
Date: Fri, 06 Jan 2017 13:13:49 -0500 [thread overview]
Message-ID: <4ishowoy3m.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <83k2aaegux.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 04 Jan 2017 21:59:34 +0200")
Eli Zaretskii wrote:
>> I think it is wrong to make autogen.sh compulsory in this way.
>
> Why do you think it's wrong?
Perhaps it's just my opinion. It was the original intent of autogen.sh
to be just a convenience wrapper for sanity checks + autoreconf.
If this is no longer true, here are some places that need to be changed:
1) autogen.sh error output says: "If you know that the required versions
are in your PATH, but this script has made an error, then you can simply
run autoreconf -fi -I m4 instead of this script."
(INSTALL.REPO used to say this too, before the IMO unrelated a3f989d
removed it.)
2) make-dist with update=yes uses autoreconf
3) top-level Makefile needs updating as per bug#25372
4) autogen.sh should ensure the outputs are newer than the inputs.
nt/gnulib.mk is only tested for existence, not freshness.
Since we use autoreconf -f, I think you can simply unconditionally
create nt/gnulib.mk every time.
All in all, it would make lifer simpler if plain automake would still
work, but I can see it might be difficult to implement.
>> (Obviously the missing file is irrelevant anyway on non MS-Windows
>> platforms.)
>
> Evidently, it isn't irrelevant, otherwise the error would have never
> happened, right?
Eg "touch nt/gnulib.mk" works just as well on non-MS platforms, where
the contents of the file are completely irrelevant.
next prev parent reply other threads:[~2017-01-06 18:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 19:36 bug#25359: autoreconf no longer suffices Glenn Morris
2017-01-04 19:59 ` Eli Zaretskii
2017-01-06 18:13 ` Glenn Morris [this message]
2017-01-06 18:25 ` Eli Zaretskii
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=4ishowoy3m.fsf@fencepost.gnu.org \
--to=rgm@gnu.org \
--cc=25359@debbugs.gnu.org \
--cc=eliz@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.