On Wed, Jan 28, 2015 at 04:38:15PM +0100, David Sterba wrote:
> Rebased on 3.18.3, fixed some minor conflicts.
>
> * I'm a bit surprised that automake is required for the
> config.{guess,sub} and install-sh files
well, it's not required, but autoconf does not provide the scripts.
You have to maintain the scripts in git three (IMHO not elegant
solution) or use the scripts from automake.
This problem does not exist if you have fully "autotoolized" project,
because automake provides automatically all the scripts.
> * my oldish testbox' automake does not support the --print-libdir option
> (automake-1.11), enterprise distros ship automake of similar age
>
> * library build test fails, but this may be because I've mismerged
> something, I'll check again
>
> Otherwise looks ok and I'll merge it, plus a few fixups to make it build
> for me.
>
> > https://github.com/karelzak/btrfs-progs/commits/autoconf
> >
> > you can merge it (now or later) on command line by:
> >
> > git pull --log g...@github.com:karelzak/btrfs-progs.git autoconf
>
> git-pulls are not (yet) established workflow, mailinglist is preferred,
> but it does not hurt to publish branches along.
OK.
> I've noticed the 'automake' branch that switches to automake. Looking at
> the amount of changes and the result, I'm not quite happy and don't see
> the benefit of automake. An extra layer that only obfuscates the build.
I don't think the set of changes is so huge, all the changes are
mostly Makefile.am.
Anyway, why automake:
- it's way how to standardize build-system, the automake rules are
really easy to read, the Makefile.am files are almost the same in
all projects.
- automake+autoconf provides AM_CONDITIONAL(), so you can keep your
makefiles pretty simple and maintain all if-then logic in ./configure
script where you have available shell and huge number of tests.
For example in util-linux we have many internal and external
dependencies, but in makefiles we have only "if BUILD_UTILNAME",
all logic is strictly in ./configure.ac
- provides large set of targets
- provides more portable environment
(for example: if you want to distribute man pages, then
dist_man_MANS += foo.8 is enough, you don't have to care about
target directories for the man page section, etc.)
- forces maintainer to generate better tarballs, after successful
"make diskcheck" you can be sure that your tarballs are really
usable (for example -- do you know how many header files are
missing in the current btrfs-progs Makefile? Do you have a way how
to check it?)
- manually write and maintain smart build-system is difficult and
result is almost always very complex stuff
There is only one disadvantage, developers have to learn something
new. Yes, people hate this thing :-)
I guess we will see more and more stuff in btrfs-progs, so it's
better to the change now than later.
See e2fsprogs (sorry Ted), it's result of "automake only obfuscates",
many Makefile.in files, '@' everywhere, nightmare.
Karel
--
Karel Zak <k...@redhat.com>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
