* Generated files in e2fsprogs git repo
@ 2014-06-30 16:52 Burton, Ross
2014-07-01 1:02 ` Theodore Ts'o
0 siblings, 1 reply; 4+ messages in thread
From: Burton, Ross @ 2014-06-30 16:52 UTC (permalink / raw)
To: linux-ext4
Hi,
Would anyone object to a patch set to remove all generated files
(aclocal.m4, configure, intl/*, po/Makefile.in.in, etc) from the
e2fsprogs git repository? They'll still exist in tarballs, but anyone
building from git would need to run autoreconf to regenerate them -
the plus side being that the shipped aclocal.m4 won't be forcing
archaic macros onto users.
Ross
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Generated files in e2fsprogs git repo
2014-06-30 16:52 Generated files in e2fsprogs git repo Burton, Ross
@ 2014-07-01 1:02 ` Theodore Ts'o
2014-07-01 9:55 ` Burton, Ross
0 siblings, 1 reply; 4+ messages in thread
From: Theodore Ts'o @ 2014-07-01 1:02 UTC (permalink / raw)
To: Burton, Ross; +Cc: linux-ext4
On Mon, Jun 30, 2014 at 05:52:29PM +0100, Burton, Ross wrote:
>
> Would anyone object to a patch set to remove all generated files
> (aclocal.m4, configure, intl/*, po/Makefile.in.in, etc) from the
> e2fsprogs git repository? They'll still exist in tarballs, but anyone
> building from git would need to run autoreconf to regenerate them -
> the plus side being that the shipped aclocal.m4 won't be forcing
> archaic macros onto users.
I don't trust autoreconf. Different versions of autoconf can end up
with different incompatible versions of autoconf macros, and I have
seen some rather disastrous failures as a result. That's why I update
autoconf under my control, and if you run autoreconf as a user, and it
breaks because the "archaic macros" work, and the "new shiny" macros
fail, that's your problem, and I will laugh at you....
- Ted
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Generated files in e2fsprogs git repo
2014-07-01 1:02 ` Theodore Ts'o
@ 2014-07-01 9:55 ` Burton, Ross
2014-07-01 15:22 ` Theodore Ts'o
0 siblings, 1 reply; 4+ messages in thread
From: Burton, Ross @ 2014-07-01 9:55 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linux-ext4
On 1 July 2014 02:02, Theodore Ts'o <tytso@mit.edu> wrote:
> I don't trust autoreconf. Different versions of autoconf can end up
> with different incompatible versions of autoconf macros, and I have
> seen some rather disastrous failures as a result. That's why I update
> autoconf under my control, and if you run autoreconf as a user, and it
> breaks because the "archaic macros" work, and the "new shiny" macros
> fail, that's your problem, and I will laugh at you....
I disagree with this position: if you're the one releasing the
tarballs then you have this control anyway - people building from git
have a higher level of technical competence assumed and using the
right versions of autoconf isn't rocket science.
My context is that we're building distributions and for every package
that uses autotools we forcibly autoreconf because the
upstream-provided configure is generally insufficient: for example
upstream libtool needs patches to cross-compile correctly, and there's
a long lag (several years) between a new architecture being developed
(two recent examples: x32 and aarch64) and it being wide-spread enough
to be in every generated configure script.
e2fsprogs is one of the handful that breaks when we do this, because
aclocal.m4 contains macros that don't come from the system (AX_TLS and
CHECK_GNU_MAKE). Simply moving these macros to acinclude.m4 should
solve this problem for us: autoconf defines that aclocal.m4 contains
copies of macros from the system, but acinclude.m4 contains
project-specific macros. I'll send a patch shortly to implement this
split.
Ross
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Generated files in e2fsprogs git repo
2014-07-01 9:55 ` Burton, Ross
@ 2014-07-01 15:22 ` Theodore Ts'o
0 siblings, 0 replies; 4+ messages in thread
From: Theodore Ts'o @ 2014-07-01 15:22 UTC (permalink / raw)
To: Burton, Ross; +Cc: linux-ext4
On Tue, Jul 01, 2014 at 10:55:51AM +0100, Burton, Ross wrote:
>
> My context is that we're building distributions and for every package
> that uses autotools we forcibly autoreconf because the
> upstream-provided configure is generally insufficient: for example
> upstream libtool needs patches to cross-compile correctly, and there's
> a long lag (several years) between a new architecture being developed
> (two recent examples: x32 and aarch64) and it being wide-spread enough
> to be in every generated configure script.
I don't use libtool at all, because I'm not a masochist.
https://plus.google.com/+TheodoreTso/posts/89xgTY49Rvk
I assume the real issue is that you need an updated version of
config.guess and config.sub. That can be easily updated without
having to use autoreconf, which is using an elephant gun to kill a
flea.
> e2fsprogs is one of the handful that breaks when we do this, because
> aclocal.m4 contains macros that don't come from the system (AX_TLS and
> CHECK_GNU_MAKE). Simply moving these macros to acinclude.m4 should
> solve this problem for us: autoconf defines that aclocal.m4 contains
> copies of macros from the system, but acinclude.m4 contains
> project-specific macros. I'll send a patch shortly to implement this
> split.
I'll look at that patch; if it's clean, I won't have a problem with
it. But I'd strongly encourage you to consider just updating
config.guess and config.sub for those projects that have the good
taste not to use libtool.
Regards,
- Ted
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-07-01 15:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-30 16:52 Generated files in e2fsprogs git repo Burton, Ross
2014-07-01 1:02 ` Theodore Ts'o
2014-07-01 9:55 ` Burton, Ross
2014-07-01 15:22 ` Theodore Ts'o
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).