[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Autotools and CMake
Re: Autotools and CMake
Mon, 29 Dec 2014 21:05:34 -0800
On Fri, 2014-12-26 at 18:46 -0700, Warren Young wrote:
> On Dec 26, 2014, at 7:56 AM, Kip Warner <address@hidden> wrote:
> > I think the logical place to "configure"
> > another subproject is within the superproject's configure script.
Hey Warren. Thank you so much for getting back to me.
> Yes, that’s better, for a reason that is not obvious, at least to me.
It took me a while to come to this solution, but my reasoning was
simple. Configuration of subprojects should take place at configure time
of the superproject, and not at build time by doing something tricky in
Makefile.am. Even though it's certainly possible to do the latter, it
just seems more rational to keep configuration happening at configure
> The bootstrap script is only supposed to be used by those building from
> the project’s VCS repository, while those building from distribution
> tarballs will just use whatever Makefiles are provided.
Yes. In my case I don't distribute a bootstrap script, nor do I use one
myself as maintainer. I ask
> The thing about CMake is that its generated Makefiles contain cmake calls, so
> they’re not independent of CMake, as Automake-generated Makefiles are
> independent of Automake. Therefore, if you ship CMake-generated Makefiles
> with your distribution tarballs, you create two problems:
This is indeed a problem and one more reason I wish they had autotooled
> 1. Those building from the distribution tarball still need cmake.
So I solved that problem by checking for it in configure.ac at configure
> 2. If the timestamps don’t force a re-generation of the Makefiles, they will
> only work on systems that are substantially similar to the one the
> distribution tarball was created on.
> Better, in the end, to simply make cmake a build prereq for all users.
> Therefore, I’d add a check for the existence of CMake on the build system to
> configure.ac, followed immediately by something like
> mkdir -p build ; cd build ; cmake ..
Already done and this part works great.
> Then in the top-level Makefile.am, in the all-local target, I’d add
> cd build ; make
Now here in lay the problem and this is where I could use some help. The
subproject is a static lib the superproject depends on. Using an
all-local isn't working the way you and I had hoped. Automake generated
its all rule in such a way that it tries to build bin_PROGRAMS first
before the subproject which, naturally, fails to link. Otherwise
all-local would be an appropriate place for this.
If I run make -k twice, it will successfully link the second time
because the subproject lib has become available, but this isn't ideal.
> I believe there are other ways to do the latter. SUBDIR_MUMBLE…?
The SUBDIR method is really problematic if the subproject is not
autotooled, or at least GCS friendly. When Automake's generated
Makefile tries to recurse into it, it fails to invoke enough rules that
one would spend an eternity trying to hack into a CMake project.
> > Would
> > you recommend AC_CONFIG_COMMANDS_PRE to run the subproject's cmake, or
> > some other method?
> I don’t see why the cmake command needs to be baked into config.status. I’d
> just put the commands somewhere in the configure.ac file, probably
> immediately after the check for the existence of CMake on the build system.
It wouldn't work anyways in retrospect because the subproject's cmake
configuration generates a pkg-config metadata file that the
superproject needs at configuration time to obtain correct compilation
/ linker flags. Running the subproject's configuration after in
config.status is too late.
> Anything found in that file that is not an Autoconf macro gets copied
> directly into the output configure script, which is a normal Bourne
> shell script.
Kip Warner -- Senior Software Engineer
OpenPGP encrypted/signed mail preferred
Description: This is a digitally signed message part