On Wed, Mar 24, 2010 at 4:04 PM, Michael Jackson <mike.jackson@bluequartz.net> 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.