On Fri, Jan 27, 2017 at 08:02:30AM -1000, Mike Frysinger wrote:
> > Right, but I'm able to create libtool without any problems and messing
> > with aclocal.m4 and acinclude.m4, et. al. I probably am relying on
> > libtoolize from the local Debian or Guubuntu build host, though. Is
> > that the issue you're having with ChromeOS? That you're using a
> > different version of the libtool/autoconf macros?
>
> if we wanted, we could do all this manually too, but i don't think it
> makes sense to force every developer to learn autotools and how to set
> up a local copy. Gwendal's patch makes things "just work" w/out
> having to learn anything new. the overhead is, arguably, negligible.
Most developers are forced to learn autotools, since it's generally
considered good practice by people who use libtools at all to not
check in build artifacts into the git tree. And developers can also
check out my xfstests-bld git tree if they wanted something completely
turnkey. Not that it's all that hard:
if test -z "$SKIP_XFSTESTS" ; then
build_start "xfstests"
(cd xfstests-dev; \
ver=$(git describe --always --dirty); echo "xfstests $ver ($(git log -1 --pretty=%cD))" > ../xfstests.ver ; \
autoheader ; autoconf ; \
CFLAGS="$LCF -I$DESTDIR/include -fno-stack-protector" \
CPPFLAGS="-I$DESTDIR/include" \
LDFLAGS="$LLF -static -L$DESTDIR/lib" \
LIBS=-lpthread \
./configure $cross ; \
make $J LLDFLAGS=$EXEC_LLDFLAGS PLDLIBS="$android_compat" \
LIBTOOL="/usr/bin/libtool --tag=CC" BUILD_VERBOSE=1)
fi
I personally don't mind checking in generated build artificats such as
"configure" into the git tree --- see how I do things with e2fsprogs
--- but I also have the good taste to absolutely consider libtool
and automake as abominations from hell. :-)
If you want to try to convince Darrin and From: Theodore Ts'o <tytso@xxxxxxx>
To: Mike Frysinger <vapier@xxxxxxxxxxxx>
Cc: Gwendal Grignou <gwendal@xxxxxxxxxxxx>, fstests@xxxxxxxxxxxxxxx
Bcc: tytso@xxxxxxx
Subject: Re: xfstest and chromeos
Reply-To:
In-Reply-To: <CAAbOScmd_j-HgZj929fbWzs3JjLkB817dJ_A-ghLyD7kHjh7GA@xxxxxxxxxxxxxx>
On Fri, Jan 27, 2017 at 08:02:30AM -1000, Mike Frysinger wrote:
> > Right, but I'm able to create libtool without any problems and messing
> > with aclocal.m4 and acinclude.m4, et. al. I probably am relying on
> > libtoolize from the local Debian or Guubuntu build host, though. Is
> > that the issue you're having with ChromeOS? That you're using a
> > different version of the libtool/autoconf macros?
>
> if we wanted, we could do all this manually too, but i don't think it
> makes sense to force every developer to learn autotools and how to set
> up a local copy. Gwendal's patch makes things "just work" w/out
> having to learn anything new. the overhead is, arguably, negligible.
Most developers are forced to learn autotools, since it's generally
considered good practice by people who use libtools at all to not
check in build artifacts into the git tree. And developers can also
check out my xfstests-bld git tree if they wanted something completely
turnkey. Not that it's all that hard:
if test -z "$SKIP_XFSTESTS" ; then
build_start "xfstests"
(cd xfstests-dev; \
autoheader ; autoconf ; \
CFLAGS="$LCF -I$DESTDIR/include -fno-stack-protector" \
CPPFLAGS="-I$DESTDIR/include" \
LDFLAGS="$LLF -static -L$DESTDIR/lib" \
LIBS=-lpthread \
./configure $cross ; \
make $J LLDFLAGS=$EXEC_LLDFLAGS PLDLIBS="$android_compat" \
LIBTOOL="/usr/bin/libtool --tag=CC" BUILD_VERBOSE=1)
fi
At least for xfstests, "autoheader ; autoconf ; configure ; make"
should be sufficient. It's really not that hard. And for cross
compilations, it's just:
cross="--build=$(config.guess) --host=$CROSS_COMPILE"
and then using "configure $cross" instead. I guess I'm not
understanding why it's considered tricky.
- Ted
P.S. I personally don't mind checking in generated build artificats
such as "configure" into the git tree --- see how I do things with
e2fsprogs --- but I also have the good taste to absolutely consider
libtool and automake as abominations from hell. :-)
Especially given that xfstests and xfsprogs only need to work on Linux
these days (we have enough other Linixisms that it would be hopeless
to get it to work on, say, BSD or Open Solaris), in my opinion the
right thing to do would be to completely ditch automake and libtool;
e2fsprogs autoconf mainly for things like "--enable-elf-shlibs" and
using Makefile fragments included as part of the configure process is
plenty to handle shared libraries. But that's up to Darrick and Eryu
to decide. :-)
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
