Hi, The preliminary CMake file in the distr. (1.38.0) is IMHO way, WAY too complex. It makes no sense to have each sublib as a separate project, and in all different flavors at that (debug/rel/mt/st). It seems as it is designed just to create the boost libraries, which in my view in a non-sensical approach of using CMake since boost is a library, not a standalone application. The CMake file should be designed for inclusion in user CMake hierarchies, so I'd like a much more simple variant akin towards this: project(boost) option(BOOST_BUILD_STATIC_LIBRARY "Build Boost as STATIC library" ON) set(BOOST_INCLUDED_LIBRARIES <list of all the sublibraries wanted/needed> ) # Collect all the files needed into variable BOOST_SOURCE_FILES using the # list from above file(GLOB ...) if (BOOST_BUILD_STATIC_LIBRARY) add_library(boost STATIC ${BOOST_SOURCE_FILES}) else (BOOST_BUILD_STATIC_LIBRARY) add_library(boost DYNAMIC ${BOOST_SOURCE_FILES}) endif (BOOST_BUILD_STATIC_LIBRARY) This way I can easily incorporate boost into my own CMake hierarchy for creating my own projects and not clutter the workspace with hundreds of projects all with different settings. Just my 2 cents. Regards /Rob Ps. Haven't checked the list for a while, so apologies if I'm kicking in opened doors.
Robert Bielik wrote:
Hi,
The preliminary CMake file in the distr. (1.38.0) is IMHO way, WAY too complex.
I think any CMake-specific discussion should take place on boost-cmake mailing list: http://lists.boost.org/mailman/listinfo.cgi/boost-cmake - Volodya
Vladimir Prus skrev:
I think any CMake-specific discussion should take place on boost-cmake mailing list:
Thanks! Will do. Regards, /Rob
Vladimir Prus skrev:
I think any CMake-specific discussion should take place on boost-cmake mailing list:
Hmmm, doesn't seem awake that list. Waiting for moderation for several days now... But, on another note: One thing that would make it easier to incorporate boost in projects via cmake is to clean up the /libs folder so it contains lib source code and nothing else. I.e. move out all test/example/sample code to another folder (/aux ?). That way it'd be so much easier :) Regards, /Rob
2009/6/5 Robert Bielik <robert.bielik@xponaut.se>:
But, on another note: One thing that would make it easier to incorporate boost in projects via cmake is to clean up the /libs folder so it contains lib source code and nothing else. I.e. move out all test/example/sample code to another folder (/aux ?).
That's unlikely, we're currently discussing moving in the opposite direction - grouping individual library's files together rather than distributing them further. But if you want the library source files they should all be in 'src' directories: http://www.boost.org/development/requirements.html#Directory_structure Hopefully everyone has followed this convention. Although there does seem to be a few 'src' directories you wouldn't want to use (eg. 'mpl/preprocessed/src', 'test/doc/src', possibly 'smart_ptr/src') so you'll have to work out which ones you want. Daniel
Daniel James skrev:
That's unlikely, we're currently discussing moving in the opposite direction - grouping individual library's files together rather than distributing them further. But if you want the library source files they should all be in 'src' directories:
As long as the sources are in /libs/<library>/src it would be fine. Then it will be easy to provide a list of the libraries to include (with *.cpp files in them). Cool! :) /Rob
I think scons will be much better for building boost. Regards. Robert Bielik wrote:
Vladimir Prus skrev:
I think any CMake-specific discussion should take place on boost-cmake mailing list:
Hmmm, doesn't seem awake that list. Waiting for moderation for several days now...
But, on another note: One thing that would make it easier to incorporate boost in projects via cmake is to clean up the /libs folder so it contains lib source code and nothing else. I.e. move out all test/example/sample code to another folder (/aux ?).
That way it'd be so much easier :)
Regards, /Rob _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
plarroy skrev:
I think scons will be much better for building boost.
Regards.
This issue is not about building boost. The issue is about including boost in a user project (which I guess is the ultimate goal?). The "CMake" way is to include CMakeLists.txt files hierarchically, thus building a workspace with all projects needed to build an application. With the current CMakeLists.txt file for boost, this is not possible (I know, boost-cmake is the proper place) since NxM projects are created (N=no of boost libs, M=4 st/mt/debug/release) Regards, /Rob
Robert Bielik schrieb:
plarroy skrev:
I think scons will be much better for building boost.
Regards.
This issue is not about building boost. The issue is about including boost in a user project (which I guess is the ultimate goal?). The "CMake" way is to include CMakeLists.txt files hierarchically,
This is not true. The most commonly used CMake way is to use FindBoost.cmake (which comes with cmake) via find_package(Boost). and thus include and link to an installed version of boost. regards Fabio
Fabio Fracassi skrev:
This is not true. The most commonly used CMake way is to use FindBoost.cmake (which comes with cmake) via find_package(Boost). and thus include and link to an installed version of boost.
Ok, its not *the* way, but when working in x-platform development (win/mac/linux) and you just want to checkout the source tree and have everything "work" directly (and not worry about what packages to install to make the project compile), its the best way imho. Working on linux I see that your described way is the normal way. Regards /Rob
Robert Bielik schrieb:
Fabio Fracassi skrev:
This is not true. The most commonly used CMake way is to use FindBoost.cmake (which comes with cmake) via find_package(Boost). and thus include and link to an installed version of boost.
Ok, its not *the* way, but when working in x-platform development (win/mac/linux) and you just want to checkout the source tree and have everything "work" directly (and not worry about what packages to install to make the project compile), its the best way imho.
I still don't agree, because you are intermingling separate modules, with the consequence that you impose certain requirements on those modules (i.e. you need them to build in a certain way, which is probably the reason for your orgiginal post). Using find_package doesn't preclude you from doing a single checkout, and have everything work. All you need to do is set the correct search path ( set (CMAKE_PREFIX_PATH <your_path>) ) before using find_package. Additionally you have a script (you can use CMake for this, too) which builds all your (external) modules in the right order. This is a bit more work to setup, but each module can be build and installed the way it is supposed to be, and work transparently. Additionally you gain a lot of flexibility, for example to test new versions of your external dependencies.
Working on linux I see that your described way is the normal way.
The same works on Windows, just as well (and I see no reason why it shouldn't work on Mac, though I haven't tried yet). Arguably it is somewhat easier on Linux, because of its superior package management. Regards Fabio
Ok, its not *the* way, but when working in x-platform development
(win/mac/linux) and you just want to checkout the source tree and have everything "work" directly (and not worry about what packages to install to make the project compile), its the best way imho.
I still don't agree, because you are intermingling separate modules, with the consequence that you impose certain requirements on those modules (i.e. you need them to build in a certain way, which is probably the reason for your orgiginal post).
Using find_package doesn't preclude you from doing a single checkout, and have everything work. All you need to do is set the correct search path ( set (CMAKE_PREFIX_PATH <your_path>) ) before using find_package. Additionally you have a script (you can use CMake for this, too) which builds all your (external) modules in the right order.
I think, but am not 100% on this, that the FindBoost.cmake included with CMake 2.6 will preempt the default search paths if you have BOOST_ROOT defined in your environment variable. I have no idea how it resolves binaries since bjam doesn't build them in an installation-like layout. Andrew Sutton andrew.n.sutton@gmail.com
Andrew Sutton wrote:
Ok, its not *the* way, but when working in x-platform development
(win/mac/linux) and you just want to checkout the source tree and have everything "work" directly (and not worry about what packages to install to make the project compile), its the best way imho.
I still don't agree, because you are intermingling separate modules, with the consequence that you impose certain requirements on those modules (i.e. you need them to build in a certain way, which is probably the reason for your orgiginal post).
Using find_package doesn't preclude you from doing a single checkout, and have everything work. All you need to do is set the correct search path ( set (CMAKE_PREFIX_PATH <your_path>) ) before using find_package. Additionally you have a script (you can use CMake for this, too) which builds all your (external) modules in the right order.
I think, but am not 100% on this, that the FindBoost.cmake included with CMake 2.6 will preempt the default search paths if you have BOOST_ROOT defined in your environment variable. I have no idea how it resolves binaries since bjam doesn't build them in an installation-like layout.
It looks in $BOOST_ROOT/stage/lib, where the libraries are placed by no-option invocation of bjam, since 1.39. BTW, it seems like this thread is becoming a general discussion of how cmake is better integrated with external projects, and *really* should be moved either to boost-cmake or even main cmake mailing list. - Volodya
participants (6)
-
Andrew Sutton -
Daniel James -
Fabio Fracassi -
plarroy -
Robert Bielik -
Vladimir Prus