Re: [Boost-cmake] Another small issue with Boost.CMake and FindBoost.cmake
Michael Jackson mike.jack...@bluequartz.net writes: On 12/16/09 1:41 PM, in article 2a66cbe0-57c7-45d4-8d44-cddc6b935...@bluequartz.net, Michael Jackson wrote: Trying things out on windows and I noticed that when I build static libraries that the names of the libraries are NOT prefixed with lib like in the bjam version of the build. This causes the FindBoost included with CMake 2.6.4 and 2.8.0 to NOT find an installed boost on Windows using Visual Studio. Where would this sort of thing be set in the CMake files? _ Mike Jackson On line 705 of BoostCore.cmake is the line that sets the library prefix using the LIBPREFIX variable. From what I can tell this cmake variable is Not set anywhere else in the build system (at least that I can find). Adding a Cmake cache entry for LIBPREFIX:STRING=lib on windows for static builds allowed the proper naming. Not sure if this is by design or got left out by accident. Maybe we need a bjam compatible mode to set all these types of things for the next few releases of boost and Cmake. At least until Cmake as it is distributed can handle the new paths in the boost installation. I'm almost certain this is simple oversight. I'm reliant on windows guys for testing. You may just be the first to look carefully at this. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Another small issue with Boost.CMake and FindBoost.cmake
Michael Jackson mike.jack...@bluequartz.net writes:
In the FindBoost.cmake file there is a line like:
# Setting some more suffixes for the library
SET (Boost_LIB_PREFIX )
if ( WIN32 AND Boost_USE_STATIC_LIBS )
SET (Boost_LIB_PREFIX lib)
endif()
Which means the Boost.Cmake project really needs to mimic this, which it
tried to do, but just missed like you said, probably just over looked it.
In that same BoostCore.cmake file there is:
if (THIS_LIB_IS_STATIC)
add_library(${VARIANT_LIBNAME} STATIC ${THIS_LIB_SOURCES})
# On Windows, we need static and shared libraries to have
# different names, so we follow the Boost.Build version 2 style
# and prepend lib to the name.
if(WIN32 AND NOT (CYGWIN OR MINGW))
set_target_properties(${VARIANT_LIBNAME}
PROPERTIES
PREFIX ${LIBPREFIX} = Probably just change this?
)
endif()
.
Change that to:
set_target_properties(${VARIANT_LIBNAME}
PROPERTIES
PREFIX lib
)
Thoughts?
Looks good to me. I'll bet LIBPREFIX was set someplace else
(BoostConfig.cmake?) at one point and was accidentially deleted during
one cleanup or other. I don't see a reason to make this
user-configurable (do you?)?
-t
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Another small issue with Boost.CMake and FindBoost.cmake
Michael Jackson mike.jack...@bluequartz.net writes: So I say go for it until someone has a problem with it. Roger. Will this be in with the changes you want me to pull? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] building boost in subdirectory
Brought over from the main cmake list. Sorry about all the top-posting.
What I came up with on this is here:
http://sodium.resophonic.com/boost-cmake/current-docs/exported_targets.html#with-boost-source-in-a-subdirectory-of-your-source
-t
Original Message
Subject: Re: [CMake] Build only what you need in third party libs
Date: Mon, 7 Dec 2009 12:26:32 -0500
From: Michael Jackson mike.jack...@bluequartz.net
To: cmake Mailing List cm...@cmake.org
References:
fe7269030912051315k2b201971m41608e6ca394f...@mail.gmail.com
811a1f290912051345l19f496ectac9257aa247ac...@mail.gmail.com
fe7269030912070847v5a52961fqbe39f1ce36afd...@mail.gmail.com
Please keep on list so that others may benefit/help
So you are wanting to include the Boost sources in your project and
you just want to build a specific subset of Boost to use with your
project?
I guess I might try setting the
# Set what boost libraries will be built
BUILD_PROJECTS=file_system;system
# Configure the Boost CMake distribution to build
add_subdirectory(boost-cmake0 ${PROJECT_BINARY_DIR}/Boost-Cmake0)
# look at
http://sodium.resophonic.com/boost-cmake/current-docs/exported_targets.html
for
# more details about the included file. Assuming it is already
generated by the time cmake
# hits this point.
include ( ${PROJECT_BINARY_DIR}/Boost-Cmake0/lib/Exports.cmake )
# Create your executable
add_executable(my_exe ${my_exe_sources} )
# Have your executable link to the boost-file_system library (and
probably the boost-system library)
# Note that the 'boost_file_system' is the actual name of a target
from the Boost-cmake0 sub project.
# See the web page linked above for more details
target_link_libraries ( my_exe boost_file_system)
I have not tried this at all, but this would be my first attempt. The
'target_link_libraries()' command will take care of all the
dependencies for 'my_exe', thus making sure boost-file_system is built
first before building the 'my_exe' executable.
Maybe someone else can comment..
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Dec 7, 2009, at 11:47 AM, Brian Davis wrote:
Yes this looks like an option. Thanks for the lead. It is not
quite what I was expecting.
This seems specific to Boost Libraries. Which brings up 2 questions:
Is there a generic way do this for any third party source tree?
Is there going to be CMAKE variable name resolution clash potential
without namespace resolution within CMake (or is there already this
problem or have I missed something)?
What I would like to do is set (please bear with me as I am a
complete nube to CMake)
BUILD_PROJECTS=none
Then do
add_subdirectory(boost_source_dir)
project( my_exe )
add_executable( my_exe mysource.cpp )
add_library( boost_filesystem SHARED)
#An IMPORTED library target references a library file located
outside the project. No rules are generated to build it. - Too bad
about this last statement
or
add_dependencies( my_exe boost_filesystem )
Is there any mechanism for project level resolution of third party
source targets such as in bjam boost//boost_filesystem
project
: requirements library../build//boost_filesystem
library/boost/system//boost_system
hardcode-dll-pathstrue
;
project boost/filesystem
: source-location ../src
: usage-requirements # pass these requirement to dependents
(i.e. users)
linkshared:defineBOOST_FILESYSTEM_DYN_LINK=1
linkstatic:defineBOOST_FILESYSTEM_STATIC_LINK=1
;
And boost_filesystem's use:
project
: requirements
library/boost/filesystem//boost_filesystem
toolsetmsvc:asynch-exceptionson
;
where some syntax like:
add_subdirectory(boost_source_dir PROJECT boost )
add_dependencies( my_exe boost//boost_filesystem )
or
add_library( boost//boost_filesystem SHARED)
allowing the specification and namespace resolution of the 3rdParty
(boost) library
I know above does not exist as my example question shows, but if it
does in some other form what is it?
Brian
On Sat, Dec 5, 2009 at 3:45 PM, Mike Jackson mike.jack...@bluequartz.net
wrote:
I _think_ you _might_ be able to set the BUILD_PROJECTS to
file_system;system then do the add_subdirectory().
Give it a shot and see what happens.
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Sat, Dec 5, 2009 at 4:15 PM, Brian Davis bitmi...@gmail.com
wrote:
I have used boost jam before and there was a mechanism to build
only what
you need by specifying dependencies within the boost libraries.
bjam would
then run off calculate deps and build only what I needed. In CMake
is there
Re: [Boost-cmake] Generation of the PDF file
Michael Jackson wrote: How is the PDF file http://sodium.resophonic.com/boost-cmake/1.41.0.cmake0/boost-1.41.0.cmake0.pdf generated? I am working with the HDF Group to move their build system to CMake and they were wanting something just like this. With the proper citations and acknowledgements, can I re-use the contents of the PDF file for the HDF5 project? The trick is to use 'sphinx' the python documentation tool. Probably what you want to do is take tools/build/CMake/doc, swap out the logo, cut out the boost-specific stuff, add acknowledgements, etc.. There's a makefile in there that will build html, latex, all kinda stuff. To get pdf you 'make latex', then in the build/latex directory there will be a makefile with a 'make pdf' target in it. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] boost 1.41.0-cmake0 and CMake 2.6.4 - The usual, CMake can not find boost.
Michael Jackson wrote: Thanks Troy. The problem is that those of us running previous versions of CMake will have a real problem with this setup. I realize I'm just the squeaky wheel here but maybe I should have helped out more to put in an option to use the bjam installation style so that some backward compatibility is maintained with CMake 2.6.4. I also just tried CMake 2.8.0 and that did not help either. Nothing from the web link works either. Patches accepted. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] boost 1.41.0-cmake0 and CMake 2.6.4 - The usual, CMake can not find boost.
Michael Jackson wrote:
Set INSTALL_VERSIONED=OFF
set BOOST_INCLUDE_INSTALL_DIR=include/boost-1_41
set BOOST_LIB_INSTALL_DIR=lib
and then go. I also set an environment variable BOOST_ROOT to the
CMAKE_INSTALL_PREFIX.
In my CMake file I have the following;
# -- Find Boost Headers/Libraries ---
SET (Boost_FIND_REQUIRED TRUE)
SET (Boost_FIND_QUIETLY TRUE)
set (Boost_USE_MULTITHREADED TRUE)
set (Boost_USE_STATIC_LIBS TRUE)
SET (Boost_ADDITIONAL_VERSIONS 1.41 1.41.0)
if ( NOT MXA_BOOST_HEADERS_ONLY)
set (MXA_BOOST_COMPONENTS program_options unit_test_framework
test_exec_monitor)
endif()
FIND_PACKAGE(Boost COMPONENTS ${MXA_BOOST_COMPONENTS} )
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
This successfully works with the FindBoost.cmake that is included with
CMake 2.6.4
OK, no worries, thanks for the working example, I've added it to the docs.
-t
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] boost 1.41.0-cmake0 and CMake 2.6.4 - The usual, CMake can not find boost.
Philip Lowman wrote: Try these docs: http://sodium.resophonic.com/boost-cmake/1.41.0.cmake0/doc/exported_targets.html YMMV. The underscores were something that bjam did. I'd really like to make a clean break with the past, I have ideas but nothing too firm yet. Not that I don't appreciate all of the hard work being done getting Boost to build with CMake, but is making a clean break with the past really a good idea here? That is to say, wouldn't it be easier on everyone if the CMake build of Boost matched the bjam defaults (especially when it comes to filename/path issues)? I don't know offhand. Are you going to say what they are and argue that position? Michael just demonstrated how to get the installation to play nice with the abomination that is FindBoost.cmake. This is now documented. You could add a flag INSTALL_WITH_FINDBOOST_BACKWARDS_COMPAT that would do those things, that'd be fine. Another possiblity is to distribute a script, say, FindBoost2.cmake that people could put into their projects that would first look for cmake-installed boosts and then fall back to FindBoost.cmake practice if they're not available. Anyhow, when I said clean break with the past, I wasn't talking about changing some underscores to dots just to be different. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Linking Debug Builds
James C. Sutherland wrote: I am using CMake in my project, but am using the CMake build of boost so that I am NOT using FindBoost.cmake. I think that you are right regarding the behavior of FindBoost.cmake. But my issue is with the BoostConfig.cmake that is installed with the CMake boost build system. James Thanks for checking in: you're right, the 1.41.0.cmake0 release has problems with this. Tronic from #boost-cmake has been helping me out and there will be fixes in the next patch release, coming soon. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Dashboar python issue
Biddiscombe, John A. wrote: The dashboard boost submission from agno has not been runnig tests for a couple of days. I had a quick look and see that although I have python turned off, something is trying to include python I believe the culprit is libs/parameter/test/CMakeLists.txt for my local copy I stuck a big IF(WITH_PYTHON) around the whole test setup, but I'm not sure this is the correct fix. Good catch, thanks. There is one test in parameter that is dependent on boost.python. I added an if(PYTHON_FOUND) around that test. There are still ways to break this, though, e.g. if PYTHON_FOUND==TRUE but 'python' not in BUILD_PROJECTS... for now we're good, will have to revisit this at some point. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Release 1.41.0.cmake0
Surya Kiran Gullapalli wrote:
One more thing I've observed is the Install target. The boost
include headers are installed in ${CMAKE_INSTALL_PREFIX}/include,
instead of ${CMAKE_INSTALL_DIRECTORY}/include/boost-1_41. I'm using
cmake for my project and cmake checks for
include/boost-1_41/boost/version.hpp file (I'm using cmake-2.8)
On linux, the include headers are installed under
${CMAKE_INSTALL_PREFIX}/include/boost-1.41.0 and libraries are installed
under ${CMAKE_INSTALL_PREFIX}/lib/boost-1.41.0
I've specified BOOST_INCLUDE_INSTALL_DIR and BOOST_LIB_INSTALL_DIR to
change them but to no avail.
Yes the build was being overly clever here. This behavior is documented
but inconsipcuously. Workaround: set INSTALL_VERSIONED to OFF, then
you can change those variables.
I've changed this behavior and cleaned up the docs a bit, this will be
in the next patch release.
-t
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Release 1.41.0.cmake0
James C. Sutherland wrote: On Nov 18, 2009, at 9:56 AM, troy d. straszheim wrote: Here's the first release for 1.41.0, take it out for a spin: http://sodium.resophonic.com/boost-cmake/1.41.0.cmake0 Get back to me here with your comments or questions. -t Why is boost::mpi disabled on apple? This is an oversight. I don't recall what the problem was. Could you just try removing the if(NOT APPLE) bits from libs/mpi/src/CMakeLists.txt and let me know how it goes? If you get errors, the output of 'make boost_mpi VERBOSE=1' and the (presumably correct) output of bjam -d2 would be useful, as well as your CMakeCache.txt -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Release 1.41.0.cmake0
Surya Kiran Gullapalli wrote: Platform: Windows. Compiler: MSVC 8.0 SP1 Boost.Cmake unable to configure iostreams with zlib (or bzip2). I've ZLIB_SOURCE env variable set to the location of zlib source code. I've also set ZLIB_INCLUDE_DIR and ZLIB_LIB_DIR in cmake-gui but it is not working. I'm getting the following errors. There are similar errors for Bzip2 as well. CMake Error at tools/build/CMake/BoostCore.cmake:1184 (parse_arguments): Syntax error in cmake code at C:/Documents and Settings/sgullapa/My Documents/Downloads/boost-1.41.0.cmake0/tools/build/CMake/BoostDocs.cmake:1187 when parsing string file_descriptor.cpp;mapped_file.cpp;zlib.cpp;gzip.cpp;LINK_LIBS;E:\Software\zlib-1.2.3;SHARED_COMPILE_FLAGS;-DBOOST_IOSTREAMS_DYN_LINK=1 Invalid escape sequence \S Call Stack (most recent call first): libs/iostreams/src/CMakeLists.txt:27 (boost_add_library) I'll have a look. Meanwhile, could you try specifying the paths with forwardslashes rather than backslashes? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CDash for boost CMake
Julien Jomier wrote: CDash should work when only experimental builds are submitted. The issue is that the submission URL is wrong: Drop site:http://my.cdash.org/CDashPublic/submit.php?project=Boost should be replaced by: http://my.cdash.org/submit.php?project=Boost Julien Yup, that was it (that url came from some very old code). I see results and the site is nice and fast, I like it. Now to get git pulling working. I'm a little lost here: % ctest -D NightlyUpdate Site: zinc Build name: gcc-4.4.1-linux Updating the repository Updating the repository: /home/troy/Projects/boost/cmake/nightly/src Cannot find UpdateCommand or GITCommand configuration key. Errors while running CTest how is this supposed to work? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Individual library testing
David Abrahams wrote: http://sodium.resophonic.com/boost-cmake/current-docs/individual_libraries.html#tests-and-examples sez: Tests and examples are typically grouped into subdirectories, e.g.: libs/ iostreams/ test/ examples/ CMake builds a parallel directory hierarchy in the build directory. If you are working on, say, the examples for iostreams, you can just cd into the directory $BUILDDIR/libs/iostreams/examples and type make: So, let's say I want to start hacking on a header-only library, e.g. Boost.Parameter. Naturally, I want to run its tests as I make changes. How do I start doing that? Set BUILD_TESTS to 'parameter'. When you reconfigure, libs/parameter/test will be generated. To build the tests, just 'make' in that directory. To run the tests, type 'ctest' in that directory. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] disabling particular external dependencies
Sean Chittenden wrote:
To have 1.41 do the right thing, be sure to set Boost_FIND_COMPONENTS
and it will populate Boost_LIBRARIES (when include()'ing
BoostConfig.cmake):
set(Boost_FIND_COMPONENTS date_time program_options system thread
unit_test_framework)
include(${CONTRIBOBJ}/share/boost-${WANT_BOOST_VERSION}/cmake/BoostConfig.cmake)
Thanks for finding these workarounds. I've tuned up, tested and
documented a bunch of this stuff. Could you try out the head of my
1.41.0 branch, using the docs that are in the checkout? I'd like to
get this worked out before the next beta comes out, I'm aiming to
release a few hours after upstream does, like last time. the
COMPONENTS business in particular should now work like the previous
version, and you should get the debug or release version depending on
your CMAKE_BUILD_TYPE
set(WANT_BOOST_LIBS date_time graph program_options regex signals
system thread unit_test_framework)
foreach(boost_lib ${WANT_BOOST_LIBS})
set(Boost_LIBRARIES ${Boost_LIBRARIES} boost_${boost_lib}-mt-d)
endforeach(boost_lib ${WANT_BOOST_LIBS})
When it comes time for unit tests, however, you get the lovely:
/opt/local/bin/g++-mp-4.3-gdwarf-2 -Wno-deprecated -g
-Wl,-search_paths_first -headerpad_max_install_names -fPIC
CMakeFiles/foo_unittests.dir/foo.cc.o
CMakeFiles/foo_unittests.dir/foo_bar.cc.o
CMakeFiles/foo_unittests.dir/foo_baz.cc.o
CMakeFiles/foo_unittests.dir/foo_bar_baz.cc.o -o
../obj/contrib-Darwin-i386/bin/foo_unittests -L/opt/local/lib
-L/Users/sean/src/obj/contrib-Darwin-i386/lib/boost-1.41.0 -lpthread
-lboost_program_options-mt -lboost_system-mt -lboost_thread-mt
-lboost_unit_test_framework-mt
Undefined symbols:
_main, referenced from:
start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
The static library unit_test_framework has a main() function, however
the .dylib/.so does not. I haven't played around with this much to find
out why yet, but thought I'd throw that out there. The problem there
came from a small change between versions:
I'll have to look in to this. I'm no expert on boost.test, but have you
checked the compile flags? IIRC you may need -DBOOST_TEST_DYN_LIB=1 or
somesuch if you intend to link to the .so. You might compare to the
bjam output by running bjam with -d2
1.41.0 set(Boost_USE_STATIC_LIBS ON)
=1.41.0 set(Boost_USE_STATIC ON)
Any chance Boost_USE_STATIC_LIBS could set Boost_USE_STATIC and throw a
depreciation warning? :) -sc
I'll investigate.
-t
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
Denis Arnaud wrote: Thanks! It eventually works :) Good. There is still a small issue, though, with a mpi.so library That is not an error. This is the python extension for MPI. Python extensions are loaded by python, they don't start with 'lib'. If you add the directory containing mpi.so to your PYTHONPATH and execute import mpi that file should be found and loaded. mpi.so will pull in libboost_python.so and libboost_mpi.so, so you may need to add the lib dir to your LD_LIBRARY_PATH as well. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] disabling particular external dependencies
Sean Chittenden wrote: I can populate the list of libs that I need by hand, but am looking for guidance on what's the right way forward. Is there a correct way to use find_package(Boost...) with an installed 1.41.0 atm? I notice Boost_VERSION is set as a string in BoostConfig.cmake but the older FindBoost.cmake that comes with cmake 2.6.4 is expecting an integer. -sc Sorry about this... you've turned up some bugs that I'm working on, I've built an entire test harness for this stuff, I expect the regression list to start dropping quickly. But for now stay tuned. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
Denis Arnaud wrote:
I forgot to mention that I still have to apply two patches (provided in
attachment, but also available on my Fedora page:
http://denisarnaud.fedorapeople.org/boost/1.40.0/10/) to alter the
configuration of CMake.
a) One is to uncomment the SOVERSION line (which, from my understanding,
is reported to fail on some platforms such as Mac), so that sonames can
be generated in the right way.
b) The other patch is to avoid building binaries (e.g., bcp, inspect).
As I have included all the possible combinations (BUILD_TESTS=NONE,
BUILD_BCP=OFF, etc), it should work for many versions of Boost-CMak
the individual BUILD_* options for tools are long gone.
BUILD_TOOLS=NONE should do it:
% cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
...
--
-- Skipping config of tools since BUILD_TOOLS is NONE
--
-- Configuring done
-- Generating done
Now, may I suggest a few enhancements, from a Fedora packaging perspective?
Yes, this is all good stuff. Keep it coming.
1. To enable the installation of the Boost libraries into the /usr/lib64
directory on 64bit Linux platforms, I currently use the
-DBOOST_INSTALL_LIB_SUBDIR_NAME=lib64 directive.
On Fedora, the RPM cmake-macro uses the -DLIB_SUFFIX=64 directive
(https://fedoraproject.org/wiki/Packaging:Cmake#RPM_Macros), though some
suggest (https://fedoraproject.org/wiki/PackagingDrafts/cmake) to
replace it by the -DLIB_INSTALL_DIR:PATH=%{_libdir} directive (where
%{_libdir} is equal to either /usr/lib or /usr/lib64, depending on the
platform).
So, I'd suggest that Boost-CMake supports one of those, as apparently
KDE4 does (http://lists.boost.org/boost-cmake/2009/10/0670.php).
Ingmar Vanhassel pointed this out, it is on the 1.40 branch:
% git branch -l
* 1.40.0
% grep BOOST_INSTALL_LIB **/*.cmake
% grep LIB_SUFFIX **/*.cmake
BoostConfig.cmake:set(LIB_SUFFIX CACHE STRING Name of suffix on
'lib' directory to which libs will be installed (e.g. add '64' here on
certain 64 bit unices))
BoostConfig.cmake:if(LIB_SUFFIX)
BoostConfig.cmake: boost_report_pretty(Lib suffix LIB_SUFFIX)
Have you got the right code?
% git log -n1
commit e26008ef3a9f94d3854e073865fe4ce3a9481ef4
Author: troy d. straszheim t...@resophonic.com
Date: Sat Oct 31 21:37:53 2009 -0400
Don't build tools by default. All they do is break.
2. To instruct CMake about the installation directory, I currently use
(http://denisarnaud.fedorapeople.org/boost/1.40.0/10/boost.spec) the
-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT%{_prefix} directive (where
%{_prefix} is equal to /usr). However, it has rpmlint (the RPM packaging
checker utility) to complain/warn about it:
$ rpmlint -i SPECS/boost.spec
SPECS/boost.spec:257: W: rpm-buildroot-usage %build %cmake
-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT%{_prefix} \
$RPM_BUILD_ROOT should not be touched during %build or %prep stage, as
it may
break short circuit builds.
Ah, I think it may be creating subdirectories of build/ during the
configure stage. Would this set off that alarm?
Also, the standard Fedora way (used by
KDE4: https://fedoraproject.org/wiki/Packaging:Cmake#Specfile_Usage ?)
is to instruct make (not cmake), like for VERBOSE=1, where to install
everything, with make install DESTDIR=$RPM_BUILD_ROOT.
So, if possible, I'd suggest that the installation directory may be
instructed at the installation stage, understood by make (and not only
by cmake).
Ah yes, DESTDIR. Have you tried it? IIRC you get DESTDIR 'for free'
with cmake, but we might be doing something to confuse it.
-t
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
Denis Arnaud wrote:
2. To instruct CMake about the installation directory, I currently use
(http://denisarnaud.fedorapeople.org/boost/1.40.0/10/boost.spec) the
-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT%{_prefix} directive (where
%{_prefix} is equal to /usr). However, it has rpmlint (the RPM packaging
checker utility) to complain/warn about it:
$ rpmlint -i SPECS/boost.spec
SPECS/boost.spec:257: W: rpm-buildroot-usage %build %cmake
-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT%{_prefix} \
$RPM_BUILD_ROOT should not be touched during %build or %prep stage, as
it may
break short circuit builds.
Also, the standard Fedora way (used by
KDE4: https://fedoraproject.org/wiki/Packaging:Cmake#Specfile_Usage ?)
is to instruct make (not cmake), like for VERBOSE=1, where to install
everything, with make install DESTDIR=$RPM_BUILD_ROOT.
So, if possible, I'd suggest that the installation directory may be
instructed at the installation stage, understood by make (and not only
by cmake).
Looking back at this, AFAICT this will work fine:
cmake ../src -DCMAKE_INSTALL_PREFIX=/usr
DESTDIR=$RPM_BUILD_ROOT make install
does this give you problems?
-t
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
Denis Arnaud wrote: 2009/11/3 troy d. straszheim t...@resophonic.com mailto:t...@resophonic.com Ingmar Vanhassel pointed this out, it is on the 1.40 branch: % git branch -l * 1.40.0 Have you got the right code? % git log -n1 commit e26008ef3a9f94d3854e073865fe4ce3a9481ef4 Author: troy d. straszheim t...@resophonic.com mailto:t...@resophonic.com Date: Sat Oct 31 21:37:53 2009 -0400 Don't build tools by default. All they do is break. I'm definitely not a git expert! Here is what I get: - $ git pull Already up-to-date. git status # On branch 1.40.0 nothing to commit (working directory clean) $ git log -n1 commit 31c30425cf29d2ae048ffb07c8284cee1e095b7a Author: troy d. straszheim t...@resophonic.com mailto:t...@resophonic.com Date: Mon Oct 26 12:52:54 2009 -0400 More docs and tweaks. Got screwed by autolinking on windows trying to get tests working. - So, obviously, I miss a few changes. But I do not know how to synchronise my clone with your master on gitorious. I've seen how to change from a branch to another, but not how to keep my clone synchronised with your master. Any help welcome! Since I see that you have a repo up on gitorious, I suspect you have a local clone of that. To pull from the main repo you first add a remote git remote add cmake git://gitorious.org/boost/cmake.git then fetch all changes from that repository git pull cmake 1.40.0 -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] 1.4.1 build problem
Treeve Jelbert wrote: using todays git checkout I used options -DENABLE_STATIC=0 -DENABLE_SHARED=1 -DENABLE_DEBUG=0 -DENABLE_RELEASE=1 [100%] Built target quickbook Linking CXX executable ../../bin/bcp /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.2/../../../../lib/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make[2]: *** [bin/bcp] Error 1 make[1]: *** [tools/bcp/CMakeFiles/bcp.dir/all] Error 2 I have gcc-4-4,2 cmake-2,8.0-rc4 boost-1.4.0 is currently installed full compile log attached Thanks very much for the testing! I don't think that I actually need bcp, so I could try to disable it if I knew how. You can just set BUILD_TOOLS to NONE: http://sodium.resophonic.com/boost-cmake/current-docs/build_configuration.html#build-tools bcp should be disabled when building only shared/release, I'll have a look. there are also lots of deprecated warnings I believe we get those for free from upstream, I suppose we could add -Wno-deprecated. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] 1.40.0.cmake4 build problem
Denis Arnaud wrote: With the 1.40.0.cmake4 version (http://sodium.resophonic.com/boost-cmake/1.40.0.cmake4/boost-1.40.0.cmake4.tar.gz), I get a build error on the binaries (e.g., bcp, inspect). [snip] To compile the inspect binary, the linker searches for the libboost_regex-mt-static library, where as the static version of that library is named libboost_regex-mt.a . I have a version cmake5 in the works, you're welcome to try the head of my 1.40.branch, where all of these should be fixed. (I'd appreciate the testing). This 1.40.0.cmake5 release contains a lot of stuff backported from the 1.41 branch. Note that there was a similar issue with the building of bcp, but I de-activated it by passing the -DBUILD_BCP=OFF option to cmake (and, for some reason, the -DBUILD_INSPECT=OFF option does not hinder the inspect binary to be built). For info, I use the following cmake options: -DBUILD_BCP=OFF -DBUILD_INSPECT=OFF -DBUILD_TESTS=NONE -DBUILD_TOOLS=NONE (I used the following documentation: http://sodium.resophonic.com/boost-cmake/current-docs/build_configuration.html#build-tools). Probably you should use the docs in tools/build/CMake/docs/build/html in your checkout... the docs at the link above are currently for the upcoming 1.41.0.cmakebeta5, already quite different from 1.40.0.cmake4. The new setup: BUILD_BCP, BUILD_INSPECT and friends are gone, now there is BUILD_TOOLS, a comma-separated list of tools to build. So BUILD_TOOLS=NONE should turn off those (useless for our purposes) utilities. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] multiple installed versions, FindBoost.cmake, exported targets, etc.
Here's what I've got. There are several options controlling how things
are built and installed, here are short descriptions:
INSTALL_VERSIONED: mangle boost version into installed dirnames
So with INSTALL_VERSIONED off:
% cmake .. -DCMAKE_INSTALL_PREFIX=/tmp/local
install layout:
Headers:
/tmp/local/include//boost/mpi.hpp
/tmp/local/include//boost/noncopyable.hpp
Installed exported targets:
/tmp/local/lib/boost/cmake/Boost.cmake
/tmp/local/lib/boost/cmake/Boost-release.cmake
Libs:
/tmp/local/lib/libboost_thread-mt.a
/tmp/local/lib/libboost_thread-mt.so.1.41.0
/tmp/local/lib/libboost_thread-mt.so
Standard CMake infrastructure:
/usr/share/boost/cmake/BoostConfigVersion.cmake
/usr/share/boost/cmake/BoostConfig.cmake
Version-specific cmake infrastructure:
/usr/share/boost/cmake/Boost-1.41.0.cmake
So here you have a 'main' unversioned install . It is possible to also
have versioned installs alongside it, but you may have only one
unversioned install.
You may have many installs via INSTALL_VERSIONED=ON:
cmake .. -DINSTALL_VERSIONED=ON
-DCMAKE_INSTALL_PREFIX=/tmp/local
Install layout:
Headers:
/tmp/local/include/boost-1.41.0/boost/mpi.hpp
/tmp/local/include/boost-1.41.0/boost/noncopyable.hpp
Installed exported targets:
/tmp/local/lib/boost-1.41.0/Boost.cmake
/tmp/local/lib/boost-1.41.0/Boost-release.cmake
Libs:
/tmp/local/lib/boost-1.41.0/libboost_thread-mt.a
/tmp/local/lib/boost-1.41.0/libboost_thread-mt.so.1.41.0
/tmp/local/lib/boost-1.41.0/libboost_thread-mt.so
Standard CMake infrastructure:
/usr/share/boost/cmake/BoostConfigVersion.cmake
/usr/share/boost/cmake/BoostConfig.cmake
Version-specific cmake infrastructure:
/usr/share/boost/cmake/Boost-1.41.0.cmake
So the only files that conflict are BoostConfig.cmake and
BoostConfigVersion.cmake in /usr/share/boost/cmake; but they don't
really conflict, because they are version agnostic.
How it works: When you do
find_package(Boost 1.41.0 COMPONENTS thread NO_MODULE)
First /usr/share/boost/cmake/BoostConfigVersion.cmake is called.
it looks for Boost-${PACKAGE_FIND_VERSION} alongside it, and if it is
there, it sets PACKAGE_VERSION to ${PACKAGE_FIND_VERSION} and so forth.
If it doesn't find the exact version it looks for the newest version,
and sets PACKAGE_VERSION to that, etc.
Then /usr/share/boost/cmake/BoostConfig.cmake is run as usual; it
simply does:
get_filename_component(CWD ${CMAKE_CURRENT_LIST_FILE} PATH)
include(${CWD}/Boost-${Boost_VERSION}.cmake)
e.g. it includes /usr/share/boost/cmake/Boost-1.41.0.cmake.
This file was generated by Boost.CMake, so it knows all about the
install, most importantly where the installed exported targets file is,
e.g. /tmp/local/lib/boost-1.41.0/Boost.cmake. It then sets up
${Boost_LIBRARIES} and all that good stuff using the imported targets.
So the following works fine, regardless of how many versions are
installed, with or without one of them installed 'unversioned', or how
strangely they are laid out:
set(Boost_USE_MULTITHREADED ON)
find_package(Boost
1.41.0
COMPONENTS thread
NO_MODULE
)
include_directories(${Boost_INCLUDE_DIR})
add_executable(main main.cpp)
target_link_libraries(main ${Boost_LIBRARIES})
Do I pass a sanity-check? It has become hard to tell. I think I'm
ready to request that Modules/FindBoost.cmake try Config mode first, so
that end users can omit the NO_MODULE in the find_package above when
cmake 2.8 comes out.
-t
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CMAKE_CXX_FLAGS on Darwin...
Sean Chittenden wrote: And when I build boost: I'm not longer seeing either of those post 1.40.0. Starting with cmake2, it looks like CMAKE_CXX_FLAGS ceased working but I don't know how or why. Is there a better way to pass CXX_FLAGS to boost? -sc I just backported a ton of stuff from the 1.41.0 branch to my 1.40.0 branch. Could you give that a try? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CMAKE_CXX_FLAGS on Darwin...
Sean Chittenden wrote: -DCMAKE_IS_EXPERIMENTAL=YES_I_KNOW \ Is this necessary any more? Heh. No, not necessary any more. What an embarrasement. Troy, will try 1.40 now and let you know. git or tarball? URL? -sc git clone git://gitorious.org/boost/cmake.git src cd src git checkout -b 1.40.0 origin/1.40.0 mkdir build cd build cmake .. I haven't attempted to add the gwarf-2 thing. But I could use some testing on that 1.40.0 branch. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix
Denis ARNAUD wrote: 2009/10/28 Denis ARNAUD denis.arnaud_bo...@m4x.org mailto:denis.arnaud_bo...@m4x.org [...] Would it be possible to have the option, with CMake build, to use a more conventional soname, so that Linux distribution packagers (Debianers and RPM-based packagers such as me, for instance) be happy (i.e., have less extra code to write)? Last year, Steve Robbins wrote http://lists.alioth.debian.org/pipermail/pkg-boost-devel/2008-November/001611.html that the Boost-CMake group could maybe add such option in the future (i.e., now). So, like this (?): % ls -l build/lib total 1352 libboost_iostreams-mt-d.a libboost_iostreams-mt-d.so - libboost_iostreams-mt-d.so.1.41* libboost_iostreams-mt-d.so.1.41 - libboost_iostreams-mt-d.so.1.41.0* libboost_iostreams-mt-d.so.1.41.0* libboost_iostreams-mt.a libboost_iostreams-mt.so - libboost_iostreams-mt.so.1.41* libboost_iostreams-mt.so.1.41 - libboost_iostreams-mt.so.1.41.0* libboost_iostreams-mt.so.1.41.0* -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix
Ingmar Vanhassel wrote: Excerpts from Sean Chittenden's message of Wed Oct 28 21:08:19 +0100 2009: Avoid pkg-config, it's very Linux and drags in a ton of dependencies (most of the time, never required, but that's the way it goes with everyone's packaging system of choice). A cmake variable would be preferred, imo (similar to the cmake boost version foo). -sc So let's make pkg-config opt-in? Totally, pkg-config is useful goodness. Use it if it's there, but not make it the primary or only way. What ton of dependencies are you referring to? At a minimum it currently requires the following to build (and their subsequent dependencies): gettext-0.17_1 gmake-3.81_3 libiconv-1.13.1 I'm fairly sure you can --disable-nls to get rid of gettext libiconv. How's it linuxy? Do you mean that it's not convenient on non-unix? pkgconfig has a tendency to suck in other gnome projects due to its gnome lineage. Ugh. If you're referring to its limited use of glib, you can disable this too, and it'll use an embedded copy of the few things it uses from glib. Not ideal, but workable. pkg-config is quite useful on linux distributions. I largely prefer using pkg-config over going back to having a gazillion foo-config binaries. I get the value of pkg-config, not arguing against it, just pointing out that we have the necessary tools in place with cmake and that cmake is well suited for solving this problem without adding additional dependencies. :) Okay, then we don't really disagree. :-) So none of these dependencies apply to us generating the file (s) necessary for pkg-config, right? I'd assumed this would be as easy as generating the file (with configure_file) and installing it to the right place. Could somebody post a template config file and instructions on where to install it? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix
Denis Arnaud wrote: 2009/10/28 troy d. straszheim t...@resophonic.com mailto:t...@resophonic.com Would it be possible to have the option, with CMake build, to use a more conventional soname, so that Linux distribution packagers (Debianers and RPM-based packagers such as me, for instance) be happy (i.e., have less extra code to write)? So, like this (?): % ls -l build/lib total 1352 libboost_iostreams-mt-d.a libboost_iostreams-mt-d.so - libboost_iostreams-mt-d.so.1.41* libboost_iostreams-mt-d.so.1.41 - libboost_iostreams-mt-d.so.1.41.0* libboost_iostreams-mt-d.so.1.41.0* libboost_iostreams-mt.a libboost_iostreams-mt.so - libboost_iostreams-mt.so.1.41* libboost_iostreams-mt.so.1.41 - libboost_iostreams-mt.so.1.41.0* libboost_iostreams-mt.so.1.41.0* Yes, exactly :) And the soname would read something like: $ readelf -a /usr/lib/libboost_date_time-mt.so | grep -i soname 0x000e (SONAME) Library soname: [libboost_date_time-mt.so.4] (that example is taken from Fedora 11, with Boost 1.37.0; the soname version is fixed within the RPM specification file). % readelf -a build/lib/libboost_iostreams-mt.so | grep SONAME 0x000e (SONAME) Library soname: [libboost_iostreams-mt.so.1.41] OK? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] Including patches other than cmake (was: 1.40.0.cmake3)
Denis Arnaud wrote: Hello, on the Boost-CMake documentation (http://gitorious.org/boost/cmake/blobs/raw/1.40.0/tools/build/CMake/docs/build/html/notes_by_version.html), boost-1.40.0-cmake3 is said to be released. However, I cannot find it on the release page (http://sodium.resophonic.com/boost-cmake/). Did I miss something, or will it be released very soon? It will be released soon, probably later today. Thanks for your attention... By the way, there were two compilation errors with boost-1.40.0-cmake2 and gcc 4.4.1 (on Fedora 11) I had to fix, gathered into a dedicated Trac ticket: https://svn.boost.org/trac/boost/ticket/3565. Hm. We can patch releases on a much shorter timescale than upstream boost does, but my original intention was that e.g. a release 1.41.0.cmakeN should be identical to upstream 1.41.0 in every way except the cmakefiles. With git, this is easy to verify. If we're going to issue patch releases that contain more than just cmake we should: 1. give them some name that indicates that they are more-than-just-cmake patch releases, 2. be careful about indicating what the diffs are (I think this can be easily scripted) 3. think carefully about what the criteria is for admitting patches. 4. continue to make releases that contain only cmake modifications. There are dangers. If people on the main boost list start getting bug reports that are due to this redistribution, they'll be justifiably angry. We really want to avoid this. Also, we're in gitland. There's nothing stopping any of you from cloning the cmake repository and pushing your patches there. Then you'd have the ability to - apply whatever patches you need - see in an instant how your distribution differs from upstream or the cmake distribution - put cmake patches someplace it is easy for me to get them. Food for thought, I'm interested in any comments. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] 1.41.0.cmakebeta3
I've just tagged up 1.41.0.cmakebeta3. Upstream is frozen for release, there should be no more changes to the codebase. Release notes: http://sodium.resophonic.com/boost-cmake/1.41.0.cmakebeta3/doc/notes_by_version.html#cmakebeta3 Downloads: http://sodium.resophonic.com/boost-cmake/1.41.0.cmakebeta3 -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] 1.41.0.cmakebeta3
Daniel James wrote: On Tue, Oct 27, 2009 at 6:03 PM, troy d. straszheim t...@resophonic.com wrote: I've just tagged up 1.41.0.cmakebeta3. Upstream is frozen for release, there should be no more changes to the codebase. It's thawed: http://lists.boost.org/Archives/boost/2009/10/157483.php And there are usually some changes during the beta period. I pulled Hartmut's patch minutes after he committed it, but thanks for the heads-up. New changes during the beta period are unlikely to affect the cmake build, and from out here in gitland merging in the new stuff as it comes is really easy, so I'm asking that people beat on the beta. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] [PATCH] Use LIB_SUFFIX, allows installing 64bit libs into /usr/lib64.
Ingmar Vanhassel wrote: Excerpts from troy d. straszheim's message of Mon Oct 26 21:37:58 +0100 2009: Ingmar Vanhassel wrote: --- tools/build/CMake/BoostCore.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Try the following patch. Use 'cmake -DLIB_SUFFIX=64 .' if you want libraries to be installed to /usr/lib64. Thanks for this. 1.41.0 is patched to support changing that lib install location via 'BOOST_INSTALL_LIB_SUBDIR_NAME'. -t Can't this use the standard LIB_SUFFIX? This is what I really hate about CMake, autotools is somewhat standardized, with CMake everyone does their own thing. Agreed. For packagers, standardization is far more interesting since we have build-scripts macros that have some sensible defaults... For users it sucks to have to look through all the CMake options to find what you named it, rather than looking whether the de-factor standard for this is available. I had no idea LIB_SUFFIX was standard. Can you point me to some examples? Of course we'll prefer the most standard thing when it exists. For that matter, it would be great if cmake supported configure-style '--prefix' and friends. Do let me know if there are more annoyances like this. Packagers are very important (at least to me), and I recognize that boost has a lot of catching up to do to be packager-friendly. That's a large part of the reason this boost-cmake effort exists. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] [PATCH] building Boost.Python fails
Claudio Bley wrote: Hi. With Boost 1.40.0 and using CMake 2.6.4 building the Python library failed because the compiler could not find some header of the parameter library. (sorry, don't have the compiler message at hand). This happend after I ran nmake modularize nmake: Thanks for the patches. I tested and pushed to 1.40.0 branch of cmake repo. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] merged to trunk (mpi tests fixed)
Hey, I went interrupt-driven for a bit and merged to trunk. Nick, I cleaned up the mpi tests while I was in there, they should make a more sensible example of how to do the graph_parallel stuff now. Unfortunately this is a difficult/complicated case... a lot of the internals of how testing is done are copy-pasted into that directory. We don't really have a good wrapper here. Feel free to commit and ping if you get stuck again... -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] link tests
I was trying to fix asio link tests and hit a couple of snags. I put in a workaround (which I bet breaks more than it fixes) and would like some feedback from kitware. The problems i was trying to fix: 1. The test is to ensure that linking against another built library succeeds. Typically cmake handles things internally with absolute paths (not with -L). How do I send the full path of e.g. boost_system, which is hidden from me, to a ctest process (which in turn invokes a cmake process, whch invokes a make process)? 2. The link tests didn't obey CMAKE_CXX_COMPILER, etc. Compile tests probably still don't... here's the diff: http://gitorious.org/boost/svn/commit/07c7e4c848af1c748a5af62d04ba86b3c99bfab5 -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Labels for known failures
Brad King wrote: troy d. straszheim wrote: Doug Gregor wrote: Note that, for these labels to work, the tester needs to be running CMake 2.7.x (which is currently in CMake CVS but isn't yet an official release). This is pretty important, because labels are also going to be used to give the library-centric view of the dashboard. Nifty... do you know if there is a way to assign a label to an entire build? I'm considering the case where I set BOOST_TEST_LIBRARIES=spirit because I'm a spirit developer and want to run my own test slave. In the ctest dashboard script that drives the build, do this: set_property(GLOBAL PROPERTY Label my-global-label) I've had a fair amount of difficulty getting ctest scripts to work. The best I've been able to come up with is 1. Configure a build space with cmake -DBUILD_REGRESSION_TESTS=ON 1a. Customize as necessary 2. Run ctest -D Whatever I've played with having cmake try to configure_file() a ctest script into the CMAKE_BINARY_DIR if BUILD_REGRESSION_TESTS is ON, but this has been problematic. What is the recommended approach? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Labels for known failures
Brad King wrote: The script can be written totally outside the source and build trees. If written properly it can do the initial checkout and create the build tree. A standalone script I use to do one of CMake's builds appears below. You can also create project-specific helper scripts like this one: [snip] SET(CTEST_CMAKE_GENERATOR Unix Makefiles) [snip] SET(CTEST_CHECKOUT_COMMAND /usr/bin/cvs -q -z3 -d:pserver:anon...@www.cmake.org:/cvsroot/CMake co -d CMakeSun -D yesterday CMake) [snip] MAKECOMMAND:STRING=/usr/bin/make -i -j2 Question #1: How do the settings in the script you posted relate to the settings found in $CMAKE_SOURCE_DIR/CTestConfig.cmake? Can they be combined? #2: What is the recommended way to handle these cross-platform bits? If you just execute 'ctest -D Nightly' in a configured directory, you don't need to touch that stuff... since the initial cmake step appears to seamlessly figure out what your generator, make command, and update commands are, the intention was to configure_file these settings over to the binary directory so that the tester's job is: 1. checkout source 2. run cmake with -DBUILD_REGRESSION_TESTS=ON 3. possibly customize a few (simple) variables in a file that was generated in step 2 (but not ones involving implementation details of cmake/ctest like CTEST_CMAKE_GENERATOR) 4. run ctest manually, in a loop, or via cron/Task Scheduler But I'm open to the idea that this doesn't make sense for some reason. Your script does make it easier to see all of the configuration in one place (very important). So we would maintain one of those scripts per platform? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CDash dashboard now available
David Wolfe wrote: x86 on what platform? I was planning to build x86 binaries for Mac OS 10.4 and 10.5. We might be able to prod someone into building x86 Windows binaries. Any takers? I'll take a stab at this if someone can help me get started. Should I do: svn co http://svn.boost.org/svn/boost/trunk boost-trunk For this package-building exercise all the relevant stuff is at http://svn.boost.org/svn/boost/branches/release since the release branch is open, my git is synced up with svn. to get the code? Troy mentioned a 'patch branch', so I'm wondering if I'm supposed to do something like this instead: git clone git://sodium.resophonic.com/boost_patches boost-cmake I tried this, and it seemed to download a ton of stuff, but then it carped: Initialized empty Git repository in c:/opt/boost-cmake/.git/ remote: Counting objects: 389135, done. remote: Compressing objects: 100% (116801/116801), done. remote: Total 389135 (delta 274306), reused 384231 (delta 269494) Receiving objects: 100% (389135/389135), 125.16 MiB | 253 KiB/s, done. Resolving deltas: 100% (274306/274306), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. Um, okay... I know mercurial pretty well, but this is the first time I've ever tried git, so somebody please tell me if I'm totally barking up the wrong tree. Basically, I'm wondering how to avoid having to redo fixes that people have already submitted patches for (e.g., setting the minor version number correctly in the top-level CMakeLists.txt file). Is there some process in place for this? Should I just hack the trunk and submit any patches against it? And who should I send said patches to? We're working on branches/release, so hack that, if anything. Again, for this you don't need to git anything from me. My patches against 1.39 are not in svn. If we do a 1.39.1 release you won't need to 'git' them. The diffs are on the webserver, look here: http://sodium.resophonic.com/git/boost_patches/?h=cmake-patches%2FBoost_1_39_0 And you'll see the four commits, which you can apply to your unpacked distribution. There are also tarball/zipfile download links in there. I've been keeping git notes, I'll see about putting up some more detailed 'how to git boost' docs. Apologies that this has been unproductive so far. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] Tool: tracking jamfile changes
I was playing around with git and put together a script to help us keep up with what is happening in bjamland. It is run every 10 minutes by a cronjob. The output is here: http://sodium.resophonic.com/cmakefiles-release-inspect.txt At the top are out of date files, that is, where a CMakeLists.txt is in a directory with a Jamfile.v2, and the Jamfile.v2 has been modified more recently than the CMakeLists.txt. Shown is the diff of the jamfile between the head, and the state at the time of the last commit to the cmakelists. At the bottom of the file are lists of missing CMakeLists.txt and those that are up to date. So if you feel like helping out, have a look in there and try to make the list smaller. That script is run every 10 minutes, you won't see results immediately. So, if you edit a CMakeLists.txt, PLEASE try to be sure that it is completely in sync with the corresponding jamfile when you commit. If there is something you need to postpone, mark it up with message(STATUS Something descriptive about what needs to be done) before you commit. I just checked and the release branch has ~3200 tests on it. We're running 2067 of them. So there is a bit of work to do yet. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Tool: tracking jamfile changes
Doug Gregor wrote: On Thu, May 14, 2009 at 11:59 AM, troy d. straszheim t...@resophonic.com wrote: I was playing around with git and put together a script to help us keep up with what is happening in bjamland. It is run every 10 minutes by a cronjob. The output is here: http://sodium.resophonic.com/cmakefiles-release-inspect.txt Very cool! Does this use git-specific features, or might it be possible to make this check part of the regression tests? It is probably possible to do in svn, I don't know for sure. It takes several minutes to run with git, it may be prohibitively slow with svn. The code is here: http://sodium.resophonic.com/git/boost_cookbook/tree/inspect_cmakefiles.sh?h=cmakefiles_monitoring At the bottom of the file are lists of missing CMakeLists.txt and those that are up to date. Cool. I see that there are a bunch of missing entries for, e.g., libs/foo/build. Our convention is to put the CMakeLists.txt file where the source code is (e.g., libs/foo/src), so I think if there's a libs/foo/src/CMakeLists.txt then we shouldn't complain about a missing libs/foo/build/CMakeLists.txt. Right. I'll clean that up. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Creating Known Issues: CMake Problems with boost 1.39
Tan, Tom (Shanghai) wrote: This is a re-post from the boost-users list, Thanks to Troy d. straszheim who reminded me there that there’s a dedicated list here. Good to see you over here I used CMake to build boost 1.39 and found at least two problems: - In the cmakelist.txt file the BOOST_VERSION_MINOR is 38, instead of 39 A known problem. You can tweak this in the toplevel CMakeLists.txt. Look for BOOST_VERSION_MINOR. I will also sooner or later put up a git branch containing all the patches we collect. - The generated boost.test libs have an additional “-s” to the file names, ex. libboost_unit_test_framework-vc90-mt-1_39-s.lib, instead of libboost_unit_test_framework-vc90-mt-1_39.lib. This will cause a linking error while using boost.test. this does not happen to the bjamed results. In the cmakefiles I see # If the STATIC_TAG flag was set, we append -s to the name of # the library. This is an unfortunate hack, needed only for the # test library. if (THIS_LIB_STATIC_TAG) set(THIS_LIB_STATIC_TAG -s) But I don't remember all the details of the hack, and I wonder if I can just create a patched version that removes this. Can you just refer to liblahblah-s from your side? Another thing I noticed but am not sure is that signal2 is not included in the CMake support(no cmakelists.txt under signals). not on the trunk or release branches either... but it is a headeronly library. Are you trying to run the tests? I've updated the docs to point out that 1.38 and 1.39 the only support is for building /installing the libraries, not for running tests within boost. I've added a Known Issues section to the docs... could you help me be sure that the information is complete? http://www.resophonic.com/boost_cmake/#known-issues -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Windows installer available for experimentation
Beman Dawes wrote: For me the next step will be to read the CMake docs a bit, look through the CMake files in the Boost tree, and generally become more familiar with CMake as it applies to Boost. Hey, This might be easiest: if you have edits, click show source on the right hand side of the docs and edit away. Just put some kind of tag next to your edits and send me the results, I'll integrate. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] Wiki to disappear: docs in progress
I've been working hard on getting some proper docs together. Whats done is here: http://www.resophonic.com/boost_cmake/index.html Not quite everything is off the wiki just yet. Bug reports welcome, help is more welcome. If you're good with restructuredtext/sphinx/git, you can clone this stuff here: git://sodium.resophonic.com/boost_cookbook they're on the boost_cmake_docs branch. That is, git clone git://sodium.resophonic.com/boost_cookbook cd boost_cookbook checkout -b my_doctweaks_branch boost_cmake_docs emacs source/*.rst alternately, you can just click the 'show source' link, get that text into an editor, hack on it, and mail it to me. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] IRC: #boost-cmake on freenode
This IRC channel exists, just FYI. A couple of us are in there if anybody feels like dropping by. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Headers erased after the first building in VC8 of boost 1.38
Trimoldi, F. (Filippo) wrote: Yes, in fact in the default configuration of my solution, both INSTALL and modularize projects aren't checked for their building, but a the end of my first building all my headers are erased... what I'm making a mistake in? I don't know. Unfortunately, I don't have any microsoft stuff here to verify. I'll guess that either there is a magic box checked someplace (I don't have any microsoft stuff in front of me right now), or the default target on windows isn't the same as it is on unix. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] trying to use non-system Python
Randy Heiland wrote: Hello, I'll post this in case someone knows the answer, while I go searching... I want to specify a non-system Python to be used, so I set the following in my CMakeCache.txt (obviously, I'm on OSX): PYTHON_DEBUG_LIBRARY:FILEPATH=path-to-my/Python.framework PYTHON_EXECUTABLE:FILEPATH=/usr/local/bin/python2.6 PYTHON_INCLUDE_PATH:PATH=path-to-my/Python.framework/Headers PYTHON_DEBUG_LIBRARY:FILEPATH=path-to-my/Python.framework However, re-config'ing, both of the LIB vars get reset to the system Python: PYTHON_DEBUG_LIBRARY:FILEPATH=-framework Python PYTHON_LIBRARY:FILEPATH=-framework Python I'm able to get away with doing this, i.e. specify non-system Python, for another cmake-based project. I'm guessing the problem has to do with FindPythonLibs.cmake Hmm. So setting those manually in your cmake cache triggers a reconf for boost-cmake, but not the other project you speak of? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] trying to use non-system Python
Randy Heiland wrote: Hmm. So setting those manually in your cmake cache triggers a reconf for boost-cmake, but not the other project you speak of? -t Correct. I think I asked the wrong question if you edit your CMakeCache.txt for any reason the makefiles will get regenerated. I just checked on ubuntu, and the python variables in the cache don't get clobbered back to 2.5 if e.g. you manually set them to 3.0. So maybe this is an apple/framework-specific thing. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] bug in Boost 1.39 (svn)
I just saw that. Fixed. Thanks. -t Kito Berg-Taylor wrote: In the current svn version of boost there appears to be a mistake in the root CMakeLists.txt file. There is an errant c on line 51. Patch included below. (Ironic location for a bug :-P) Index: CMakeLists.txt === --- CMakeLists.txt (revision 51607) +++ CMakeLists.txt (working copy) @@ -51,7 +51,7 @@ message(STATUS Subscribe to the mailing list:) message(STATUS http://lists.boost.org/mailman/listinfo.cgi/boost-cmake;) message(STATUS ) -message(STATUS NOTE: Please ask questions about this build system on the boost-cmake list,)c +message(STATUS NOTE: Please ask questions about this build system on the boost-cmake list,) message(STATUS not on other boost lists.) message(STATUS ) message(STATUS And/or check the archives:) ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Headers erased after the first building in VC8 of boost 1.38
Trimoldi, F. (Filippo) wrote: I generated a Boost.sln solution for VC8 with the new system CMake. ( using this command: cmake -DCMAKE_IS_EXPERIMENTAL=YES_I_KNOW CMakeLists.txt in root directory of the boost ) When I try to build the entire solution all thinks goes good without problem. But only the first time. In fact, at the end of this first building all the headers are erased from the boost the directory. So I cannot make another building and I have to recover the headers file by other ways. I'm not sure what target you are building... the 'install' target requires 'modularize' and this is a one-way process, the headers will be modularized such that rebuilds aren't possible. The default target doesn't rearrange any headers, and rebuilds work fine. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Build failures on Mac OS X 10.5
E. Wing wrote: Does anybody know how to get/build universal binaries for ICU so I can get the Boost build to work as universal? No... but do let us know if you get the details. Thanks, -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Build failures on Mac OS X 10.5
Michael Jackson wrote: What build system is ICU using? You may have to add the -arch ppc -arch i386 flags yourself on the command line using something like CXXFLAGS=-arch ppc -arch i386 You can use bjam to get a universal build of Boost. If it is just a matter of adding some CXXFLAGS it shouldn't be difficult to do it with cmake either... or am I missing something? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Build failures on Mac OS X 10.5
Michael Jackson wrote: Well, basically I am confused. Is ICU bundled with Boost? It has been a Long time since I dug into the boost sources. Any system-install ICU is just detected by cmake (see tools/build/CMake/FindICU.cmake), and boost builds against it, if it is there. And, yes, CMake has the CMAKE_OS_X_ARCH variable which you can set to any combination of ppc,ppc64,x86,x86_64 for any where from a single binary to a quad binary. Ah, there we go. Thanks. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Build failures on Mac OS X 10.5
Hey, E. Wing wrote: /Developer/usr/bin/libtool: unknown option character `W' in: -Wl,-u,_munmap I'll look in to this one. Workarounds: if you don't need the static libs you can just turn BUILD_STATIC off. Alternately, if you don't need boost::mpi, you can turn BUILD_MPI off. CMake Error at libs/preprocessor/cmake_install.cmake:31 (FILE): file INSTALL cannot find file /Users/ewing/Downloads/boost_1_38_0/libs/preprocessor/include/boost to install. Call Stack (most recent call first): libs/cmake_install.cmake:32 (INCLUDE) cmake_install.cmake:37 (INCLUDE) This one is a gotcha. You have to 'make modularize' before you 'make install'. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] Boost 1.38.0 released (installer time?)
One reason for my request to merge to the release branch was so that these fancy binary installers could get built from the release itself and not from some hacked-up branch. So those of you who like these things are free to experiment with cmake's 'make package'. You need to 'make modularize' first. I made one for OSX which looks good (didn't test very thoroughly), the welcome message and whatnot are cmake-default and will need tweaking, but given that we're 'Experimental' what is there is probably fine. -t Original Message Subject: [boost] Boost 1.38.0 released Date: Mon, 9 Feb 2009 19:40:56 -0500 From: Beman Dawes bda...@acm.org Reply-To: bo...@lists.boost.org To: Boost Developers List bo...@lists.boost.org Boost 1.38.0 has been released and is available from SourceForge. See http://sourceforge.net/projects/boost/ This release includes three new libraries: Flyweight, ScopeExit, and Swap. Updated Libraries: Accumulators, Any, Asio, Config, Date_Time, Exception, Filesystem, Graph, Hash, Interprocess, Intrusive, Lexical Cast, Math, Multi-index Containers, Proto, Regex, Thread, TR1, Type Traits, Unordered, and Xpressive. Other Changes: Experimental CMake build system. You can read the full release announcement here: http://www.boost.org/users/news/version_1_38_0 The release managers were Beman Dawes, Daniel James, Eric Niebler, and Rene Rivera. --Beman Dawes ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Analysis of the current CMake system
Ingo Albrecht wrote: Note that vcbuild (the command line driver for VS builds) has command line arguments for specifying strings to prefix log messages at various log levels with. This should make log scraping of the compilation much more reliable, although it still disgusts me. This does not work for CTest though because it tests using cmake scripts. Running vcbuild is certainly no alternative for trying the build in the IDE, but it should be sufficient for continuous integration. Further, I have to note that command-line VS builds should be supported for one simple reason: nmake does not support parallel builds and probably never will. This makes VS the easiest way of running a parallel build on Windows (locally or distributed with additional tools). GNU make from MSYS is out of the question because MSYS seems far from production-grade. Should IDE builds be considered support-worthy, it would of course be necessary to test manually before releases. I hope that some of this helps Interesting, thanks for this. Would the 'cwrap' approach (where the compiler is called via a wrapper) work under vcbuild? (Forgive me, I don't do windows). The only reason I paid attention to NMAKE is that it was somewhat familiar to me. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] [boost] RE Boost 1.38.0 beta 2 available
(pulled over from main boost list) Beman Dawes wrote: Yes. There will be a lot more discussion and review before V3 ships. I keep hoping someone will volunteer to fix Cygwin, too. Things looking fine for an experimental release, but is it OK to commit cosmetic fixes, small tweaks to the CMake build on the release branch (not to code, to CMakeLists.txt only)? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] README.txt and Welcome.txt?
Daniel James wrote: I've added a note to the changelog and the groups page on the beta site. If there are any other pages you'd like me to change, let me know. http://beta.boost.org/community/groups.html#cmake http://beta.boost.org/users/news/version_1_38_0#version_1_38_0.other_changes Perfect. Thanks! If you want to, you should be able to change the website yourself, the details are at: http://beta.boost.org/development/website_updating.html and thanks again. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Analysis of the current CMake system
Hi Brad, There is a lot to discuss here. I'll go back later and make specific comments. It'd be great to talk in person at boostcon, (boostcon rocks, by the way.) I understand/agree with a lot of your points (especially bulkiness, and the need to reduce the number of toplevel targets), in most cases because I've learned more about cmake since I implemented what is currently on the boost trunk. Brad King wrote: [snip] In summary, I'd like to help you folks address these issues. Some of the work will be in Boost's CMake code and some in CMake itself. The work will benefit both projects. We can arrange to meet at BoostCon, but we can probably get alot of discussion done on this list before then. BTW, can anyone suggest a preferred format for a BoostCon session from the boost-cmake-devs' point of view? I don't personally see a formal presentation to boost-cmake devs as being useful, there just aren't enough of us (last I checked there were three). I'd suggest we just sit down together... there are plenty of conference rooms available at all times. The boost-cmake-for-users talk could of course reflect whatever we get done between now and then. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Boost CMake at BoostCon?
Beman Dawes wrote: On Fri, Jan 9, 2009 at 11:27 PM, David Abrahams d...@boostpro.com wrote: on Fri Jan 09 2009, Beman Dawes bdawes-AT-acm.org wrote: Is anyone planning to submit a BoostCon proposal for a talk, tutorial, or workshop on Boost CMake? Seems like this would be a natural to build momentum. I've been considering that. My orbit is coming back around... I've been planning to submit a talk on the state of boost-cmake. Just booked my hotel room. Should I proceed or does somebody else want to take this one? Great! Here are some off the top of my head thoughts, intended to stimulate discussion: It seems to me that there are several different Boost CMake tasks someone might want to accomplish, and documentation and/or training needs to be oriented toward those tasks. The tasks might be broken down like this: 1) Build one or more libraries, possibly with variants. 2) Test one or more libraries locally. 3) Set up simple build and test configurations for a library that does not require any deep understanding of Boost CMake. 4) Learn enough about Boost CMake to be able to set up complex configurations, or set up configurations that do not follow the standard patterns. Be able to support other users and help maintain Boost CMake. Docs for tasks 1-3 should contain only material relevant to the task at hand. IOW, be very task oriented. For BoostCon, it would be great if there was one session that covered a bit of an overview and then how to accomplish tasks 1 and 2, and then another session (or sessions) were devoted to 3 and 4. The 1-2 session would be a prerequisite for the 3-4 session, at least for those with no prior exposure to CMake. Sounds reasonable to me. It isn't clear to me that this would take two sessions, you could probably do it all in 60-90 minutes, maybe before lunch: do the task-oriented part first, then announce that those who aren't interested in gory details can split. I suppose we should plan for some birds-of-a-feather type sessions as well. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Regression Test Reporting
troy d. straszheim wrote: One thing that has changed since that discussion is tests-as-first-class-targets: for boost, at least, the extra cost in generation time and time-to-build is prohibitive, and the regex-selection style of ctest (-R mylibrary) is more straightforward and functional. (You get situations where you want to specify that certain tests are run in order, and doing this with make-target-dependencies is a big hassle). I forgot to include that this is my current opinion... this isn't implemented in boost, and there are loose ends to think about there, like compile_fail type tests. I've implemented it elsewhere though and like it. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] boost cmake status
Mike Jackson wrote: Also, do you need a tester for OS X? I am running 10.4.11 Intel and would be happy to try and setup some sort of script to download and test regularly. Hey Mike, I'll take you up on that, I'd definitely like some testers. I'm many time zones from home right now but will be back this week and will ping the list with updated instructions on running a testing drone. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Access to test reporting database?
Beman Dawes wrote: Are the results of the CMake based regression testing stored in a database I can access? Here's a dump, 865k rows: http://boost.resophonic.com/mysql.trac.gz The tables you are interested in are traash_build and traash_step, the rest are used by trac itself for bookkeeping. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] What we're doing testing-wise (was Status and future of boost-cmake)
Miguel A. Figueroa-Villanueva wrote: - Is there a CDash dashboard actively running? It seems that the http://dart.resophonic.com/boost_1_34_0/Dashboard has been down for the last 4 days at least... Troy's been working on an updated system that isn't based on CDash. I haven't been keeping up with it as well as I should, but I expect we'll see more cool stuff from him later on. I'd like to know the details here... if it is ctest/CDash I can help to set these up and later in august I could probably setup a public dashboard (Now the network administrator that is in charge of the equipment is in vacation and I need him to resize the virtualized qemu image). I think what we're doing here is pretty compelling. The working title is 'traash' (trac + dash). We're *not* using ctest/cdash/dash or any of that. See the archives for this list, there are some long threads there that explain the reasoning. See also tools/build/CMake/BoostTesting.cmake and tools/build/CMake/BoostBuildSlave.cmake, and the various python scripts that do the low-level work: tools/build/CMake/*.py.in. There are user docs at http://svn.boost.org/trac/boost/wiki/CMakeForRegressionTesters and the 'dashboard'/trac plugin is at http://boost.resophonic.com/trac/traash There is a 'build slave runner' script named run_continuous_slave.py that is put into your build directory that runs incremental builds similar to how 'ctest -D Continuous' does. This business of setting up build slaves, continuous/nightly builds, configuration, etc, tends to be brittle but needs to be solid as a metal desk... a lot of the users won't be experts. Any development/testing/documenting that you might feel like doing here is most welcome. The dashboardish trac plugin is slow (for various fixable reasons) and needs more features (it only has a couple of views), but it is easy to extend and I already find it useful. I think it won't be long before we are more effective at communicating the current state of the release branch than the current testing system is, even with far fewer people and machines. I expect this to be a big help making our case. The long-term intention here is to factor out the client-side cmake/python infrastructure and post the trac plugin on trac-hacks, making this thing generally available to cmake/trac based projects. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] auto-modularization. Time to merge to main release branch?
Doug Gregor wrote: On Wed, Jul 2, 2008 at 4:45 PM, Beman Dawes [EMAIL PROTECTED] wrote: What is the status of using CMake to run regression tests? What is the status of using CMake to run developers local tests? Troy's the master here :) On the client side, regression testing works well, I've had build slaves running for quite some time. It needs exercise, users that are willing to tweak and document. The server (trac plugin) side needs more different fancy displays of results, summarys, some performance tuning, etc. Running individual developer tests works fine but could use some kind of nice summary display. Until CMake is ready to take over both of those tasks, I don't want to see it merged into trunk. It will just cause confusion. I'm very concerned that Rene and I will have the CMake stuff dumped on us long before it is ready to take over from Boost.Build. If it isn't in trunk, then that won't happen. But if it is in trunk then there will be pressure to use it, even if not ready for prime time. Boost.Build version 2 was in the trunk for literally years before we made the switch, and I don't recall that it caused all that much confusion. Having CMake in the trunk brings us real benefits, and of course it will be clearly marked experimental or in-progress. I think there is zero chance that the Boost.Build community will simply disappear. The cmake configuration phase could display a big banner * * THIS IS NOT AN OFFICIAL BUILD SYSTEM FOR BOOST DO NOT ASK BEMAN OR RENE ABOUT THIS KEEP MAIL TRAFFIC OFF OF boost-users COME SEE US AT boost-cmake@lists.boost.org * * ... don't know how else to reassure on this. Having to constantly merge with the trunk is costing me a lot of time I don't have, and it would be nice if those who are already interested in cmake could see the CMakeLists.txt in the tree and come over to this list and give the code some exercise. Surely there is a library author or two who is already familiar with cmake and is willing to maintain their own CMakeLists.txt... and this is user experience/feedback that we need and don't have. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Cmake Boost Libraries
Beman Dawes wrote: Doug, you need to explain this to us Windows developers who don't have a clue as to how to manage multiple build variants of libraries without name mangling. I don't think it is absolutely necessary to do so. Again, CMake can mangle, or not. FWIW, I'm working on a commercial project now where developers are unhappy with Boost because we don't include 32-bit/64-bit builds in the name mangling. These same folks decide not to use name mangling in their own libraries, and as a result are running into constant hassles. Note that this isn't an issue of different compilers, but rather debug | release, and 32-bit | 64-bit builds with the same compiler. Here's more evidence that any mangling should be off by default but configurable. The current mangling scheme isn't detailed enough for some (and I can think of a number of unixy situations where having release/debug 32/64 in the name might make sense but not all), too detailed for others, and inflicts a lot of unnecessary complexity on basically everybody else. Apparently no one scheme will do. Also note that these guys aren't in the 'getting started' phase, they know how they like their mangling. It isn't asking much of them to go to the 'mangling' section of the docs and configure it as they want it. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Some issues getting started on Win32
David Abrahams wrote: troy d straszheim wrote: Things look good. So... Dave is it possible you were doing configuration of cmake in a build directory that had failed configuration once? Gosh, I don't know. Maybe. Probably. Heck, shouldn't that work, after all!? How will our users survive if one failure torpedoes all further attempts? It is just a standard cmake gotcha:configuration/generation fails, the cache isn't deleted, and whatever it was that caused the failure is preserved in the cache to fail on the next attempt. You can reduce this effect by being careful what you cache, but in this case, well, we're still just hackin' on this thing -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Some issues getting started on Win32
troy d. straszheim wrote: On the CMAKE_RC_COMPILER: we saw this error as well... then it mysteriously disappeared, we didn't manage to toggle it and document how. I looked at this again, here are a couple of observations: Visual studio includes a .bat file that appears to load the VS environment into a running command prompt session. Mine is located at c:\Program Files\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat I can do the following from a vanilla command prompt window (not the one from the visual studio submenu) c:\boost\branches\CMake\releasemkdir bld c:\boost\branches\CMake\releasecd bld (../src contains a checkout of the cmake release branch) c:\boost\branches\CMake\release\bldcp ../src/BuildSlave.cmake . c:\boost\branches\CMake\release\bldnotepad slave-description.txt c:\boost\branches\CMake\release\bldtype slave-description.txt vista build slave c:\boost\branches\CMake\release\bldcmake -C BuildSlave.cmake ..\src loading initial cache file BuildSlave.cmake -- Reading initial cache for build slaves. -- Will take build details from slave-description.txt -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found. Ple ase set CMAKE_RC_COMPILER to a valid compiler path or name. -- Check for CL compiler version -- Check for CL compiler version - failed -- Check if this is a free VC compiler -- Check if this is a free VC compiler - yes -- Check CL platform -- Check CL platform - 64 bit -- Using FREE VC TOOLS, NO DEBUG available -- Check for working C compiler: cl CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found. Ple ase set CMAKE_RC_COMPILER to a valid compiler path or name. CMake Error: your C compiler: cl was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: cl -- broken CMake Error at C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/CMakeTestCComp iler.cmake:32 (MESSAGE): The C compiler cl is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:28 (project) CMake Error: your C compiler: cl was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: your CXX compiler: cl was not found. Please set CMAKE_CXX_COMPI LER to a valid compiler path or name. -- Configuring done Now, if I run that .bat file from the visual studio install: c:\boost\branches\CMake\release\bldC:\Program Files\Microsoft Visual Studio 9. 0\Common7\Tools\vsvars32.bat Setting environment for using Microsoft Visual Studio 2008 x86 tools. That much looks good, but if I simply rerun cmake: c:\boost\branches\CMake\release\bldcmake -C BuildSlave.cmake ..\src loading initial cache file BuildSlave.cmake -- Reading initial cache for build slaves. -- Will take build details from slave-description.txt -- The C compiler identification is MSVC -- The CXX compiler identification is MSVC CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found. Ple ase set CMAKE_RC_COMPILER to a valid compiler path or name. -- Using FREE VC TOOLS, NO DEBUG available -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio 9.0/VC /bin/cl.exe CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found. Ple ase set CMAKE_RC_COMPILER to a valid compiler path or name. CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio 9.0/VC /bin/cl.exe -- broken CMake Error at C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/CMakeTestCComp iler.cmake:32 (MESSAGE): The C compiler C:/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl.exe is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:28 (project) -- Configuring done But this appears to be a failure of cmake, not the environment. If you then delete the CMakeCache.txt and rerun: c:\boost\branches\CMake\release\bldrm CMakeCache.txt c:\boost\branches\CMake\release\bldcmake -C BuildSlave.cmake ..\src loading initial cache file BuildSlave.cmake -- Reading initial cache for build slaves. -- Will take build details from slave-description.txt -- The C compiler identification is MSVC -- The CXX compiler identification is MSVC -- Check for CL compiler version -- Check for CL compiler version - 1500 -- Check if this is a free VC compiler -- Check if this is a free VC compiler - no -- Check CL platform -- Check CL platform - 32 bit -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio 9.0/VC /bin/cl.exe -- Check
Re: [Boost-cmake] Test feedback
Beman Dawes wrote: I went back and set BOOST_BUILD_SLAVE_HOSTNAME to vista.dc.resophonic.com http://vista.dc.resophonic.com/, then tried nmake /I test. It runs for a bit and then pauses for a long time, then runs a bit more, etc. At this rate it will take days to run the full set of tests. Is that normal? I've seen this but haven't had time to dig in and solve it yet. CPU usage drops to zero and the thing just sits there Yes, those are the symptoms I'm seeing here. (there is no network connection open, that isn't the problem). There is something fishy with the python subprocess stuff (on windows. darwin/linux are fine.) that I haven't had time to look at. Any Python win32api experts out there who could look at this? It looks like you can fix this pretty easily by using subprocess.communicate() instead of subprocess.wait(), but then you get other problems with Visual Studio Debug Library Assertion Failure Popups, how to monitor/timeout the subprocesses, etc. I created a ticket on this one as well: http://svn.boost.org/trac/boost/ticket/2043 -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Some issues getting started on Win32
On the CMAKE_RC_COMPILER: we saw this error as well... then it mysteriously disappeared, we didn't manage to toggle it and document how. It looks like there are some variations in the way visual studio gets installed that are relevant: http://www.cmake.org/Bug/view.php?id=5719 [note that the 'proposed solution' bit doesn't start until after the rather long how-to-reproduce] On the 64 bit problems... will look later. -t Niels Dekker - mail address until 2008-12-31 wrote: David Abrahams wrote: * on Win32, invoking cmake from inside my Visual Studio 2008 Express command prompt window, I get S:\xp32\build\boost-cmakecmake . -- The C compiler identification is MSVC -- The CXX compiler identification is MSVC CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found. Please set CMAKE_RC_COMPILER to a valid compiler path or name. -- Using FREE VC TOOLS, NO DEBUG available -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio 9.0/VC /bin/cl.exe CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found. Please set CMAKE_RC_COMPILER to a valid compiler path or name. CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl.exe -- broken CMake Error at C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/CMakeTestCCompiler.cmake:32 (MESSAGE): The C compiler C:/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl.exe is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:28 (project) -- Configuring done FWIW, I have Visual Studio 2008 Team Edition installed here (Win XP, 32 bits), and it doesn't have an RC.EXE either. Even though http://msdn.microsoft.com/en-us/library/hs24szh9.aspx suggests that RC.EXE is included with all editions of Visual C++ 2008. Luckily I still had a few RC.EXE's at my disc: C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\RC.Exe C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\rc.exe C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\Bin\RC.Exe So maybe you need to install Microsoft SDK...? Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
