|
|
Boost Interest : |
Subject: Re: [Boost-cmake] Building boost "with an uninstalled build" and linking to boost libs
From: Brian Davis (bitminer_at_[hidden])
Date: 2010-03-25 00:10:03
On Wed, Mar 24, 2010 at 4:04 PM, Michael Jackson <
mike.jackson_at_[hidden]> wrote:
> I have been playing with "ExternalProject_Add" and I don't think you are
> going to be able to do what you are trying to do. I was using the following:
>
>
Yes exactly which is why I switched to "with an uninstalled build". I also
made reference to the brokenness and chicken-and-the-egg problem
>
> The problem is that all the files that Find_package() would normally use
> are NOT available the first time CMake is run. They would ONLY be available
> after boost is compiled and installed. So this seems to be a chicken-and-egg
> thing. Not sure what to do except ask on the CMake Users Mailing list.
>
>
Yep I know... exactly. Here is the question I asked on the CMake mailing
list: Why can't Find_package know where a package will be (as well) before
compilation not just where it is after. I think the build system has every
thing it will need to know this in the build spec and if it does not... well
time to redesign CMake. As far as the CMake Users Mailing list... I have:
http://www.cmake.org/pipermail/cmake/2010-January/034283.html
I mean think about it for a moment... BoostCore.cmake generates a list of
dependencies and specifies where the output files will be. Why do we need
to do a build to FindBoost. We know where it will be. The targets need to
be specified (from my current understanding) in BoostCore.cmake, and maybe
they are... I am still trying to digest this file, but seemingly it does not
as ${Boost_FILESYSTEM_LIBRARY} and friends are only generated in FindBoost,
but not in BoostCore.cmake which I am sure is by design based on CMake
methodologies.
There have been references made to about boost "abusing" CMake as a build
system. I look at the Boost Build system as a godsend expecialy when I was
developing for embedded targets and doing cross compilation to various
targets. IMHO I think CMake can use to grow and learn from these types of
stress tests. I mean how hard is it to create a build tool that can preform
dependency checking across multiple 3rdParty libs? I am presume that
inorder for CMake to be able to handle this there needs to be the concept of
namspaces for variables relating to the 3rdParty libs eliminating the name
clashing problem (much like BoostCore.cmake prepends almost all :-(
variables with BOOST_ . I also liked the /boost//filesystem syntax in
Jamfiles.v2. The Boost.Build v2 version of projects seemed much cleaner and
solved this namespace issue (at least as far as dependencies were concerned
- the problem was still there as far as global variables were concerned) I
could also build all build variants in one command line. Not so with CMake,
at least not that I can determine.
-- Brian J. Davis