On Fri, Jan 27, 2017 at 2:10 PM, Theodore Ts'o wrote: > 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. i have no idea what you're trying to argue here. (1) xfstests already uses autotools. disliking autotools doesn't change that. (2) developers don't need to learn anything new. you always run `autoreconf -fi`. FIN. there is no need to figure out which specific sub-tools to run (autoheader, autoconf, libtoolize, whatever), or in what order. if you're worried about people not knowing how to run this one command, then we can add an "autogen.sh" script to the root to run `autoreconf -fi` for you. that's a semi-common practice in autotool based projects. (3) no one (on the CrOS side) is arguing for committing generated artifacts into git. that's a terrible practice regardless of autotools. > 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. :-) so we trade one pile of standard scripts/hacks that the rest of the world uses for a pile of non-standard/unique scripts/hacks that only one project uses ? that doesn't sound like an improvement, it just sounds like "this is the pile i know". except in the case of xfstests, it isn't something we know. -mike -- 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
