Re: [Boost-cmake] Discussion of Boost-cmake moving forward

On 08/26/2010 11:48 AM, Michael Jackson wrote: > These are some emails between me (Mike Jackson) and Denis about how to move > forward with Boost-cmake. Troy started this wonderful project but now needs > some help. Denis and I are ready to step up and help where can but we need > some support from

Re: [Boost-cmake] multiple installed versions, FindBoost.cmake, exported targets, etc.

troy d. straszheim wrote: > 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. [snip] > Do I pass a sanity-check? It has become hard to tell. It is an interesting app

Re: [Boost-cmake] RFC sonames initial implementation

troy d. straszheim wrote: > Brad King wrote: >> Perhaps the boost CMake code is not setting SOVERSION. > > Hmm. It isn't setting it on purpose... If I set either VERSION or > SOVERSION on a module on the mac, I get: [snip] > ../../../lib/libboost_python-mt.1.41.0.dyli

Re: [Boost-cmake] RFC: exported targets

troy d. straszheim wrote: > Ingmar Vanhassel wrote: >> Excerpts from troy d. straszheim's message of Thu Oct 29 23:18:12 >> +0100 2009: >>> I haven't forgotten about LIB_SUFFIX. It is footnoted in the >>> exported targets section of the docs: >> >> I meant the cmake/ subdirectory, to avoid clutter

Re: [Boost-cmake] RFC: exported targets

troy d. straszheim wrote: > if you link to > boost_threads-mt-shared, for instance, with the installed exports you > automagically get -pthread and friends, but with the noninstalled > exports you don't. Is this expected? It should work for both. Make sure that the export() command for a target

Re: [Boost-cmake] RFC: exported targets

Ingmar Vanhassel wrote: >> Yes. This is a great cmake feature. Boost.CMake now uses this to >> install a $PREFIX/lib/Boost.cmake file. > > Can we agree on $PREFIX/lib$LIB_SUFFIX/cmake/Boost.cmake please? > > Also, some users may want to install multiple versions of boost, so I'd > shove $BOOST_

Re: [Boost-cmake] RFC: exported targets

troy d. straszheim wrote: > Michael Jackson wrote: >> This is THE SINGLE IMPROVEMENT someone could make for those of us >> using CMake and are dependent on the boost libraries. > > I did some work on this. CMake exported targets are really cool. This > doesn't solve the entire FindBoost.cmake pr

Re: [Boost-cmake] FindBoost.cmake

troy d. straszheim wrote: > Currently we work with cmake back to 2.6.4, I'd like to do something > that works independently of cmake's Modules/FindBoost.cmake (I'm frankly > afraid to even look inside that file). CMake will prefer that file > unless NO_MODULE is specified, so for users of cmake th

Re: [Boost-cmake] RFC sonames initial implementation

troy d. straszheim wrote: > Is there some standard buildtime toggle for this, or is > BUILD_SOVERSIONED okay? There is no standard AFAIK. > The option is avaiable on UNIX only. Note that setting VERSION does set the windows "image version" in DLLs, but it does not affect the file name. > The im

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Denis Arnaud wrote: > > 2009/10/28 Vladimir Prus > > > This might be obvious, but such a soname would be wrong if the above > naming > of libraries is used, since there would be no > libboost_date_time-mt.so.4. > > - Volodya > > > I've jus

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Michael Jackson wrote: > This is THE SINGLE IMPROVEMENT someone could make for those of us using > CMake and are dependent on the boost libraries. Finding Boost with CMake > is historically a pain and is extremely error prone. There is no support > for future versions in the current FindBoost. You

Re: [Boost-cmake] Testing dependencies

Beman Dawes wrote: On Mon, Jun 8, 2009 at 9:17 AM, Brad King wrote: However, the major step before that is to package all tests for each library into test-driver executables. This is useful whether using bjam or CMake because it drastically reduces the total link time and disk space used for

Re: [Boost-cmake] Testing dependencies

Vladimir Prus wrote: This is what Troy's custom-target-per-test approach last year tried to do, but it was not scalable. In what way, and why and can *that* be fixed? Troy's solution used one add_custom_target() for each test. This translates into one .vcproj file per test on Visual Studio

Re: [Boost-cmake] CMake thoughts

Michael Jackson wrote: What _really_ needs to be done, for BOTH the bjam and the cmake based builds is to produce a "UseBoost.cmake" file akin to the UseQt4, UseVTK, UseITK, UseParaView that are either included with CMake or produced by the build system then installed into the installation loca

Re: [Boost-cmake] Testing dependencies

David Abrahams wrote: I just realized we need a feature (surprise!) When I'm working on a Boost library, I need to be able to fire off all the tests of libraries that depend on the one I'm changing, to make sure I'm not breaking anything in the library collection before I check in. We discusse

Re: [Boost-cmake] CMake for development testing

David Abrahams wrote: 67/ 79 Testing Python-resultPassed 68/ 79 Testing Python-string_literal ***Failed 69/ 79 Testing Python-borrowed ***Failed 70/ 79 Testing Python-object_managerPassed 71/ 79 Testing Python-copy_ctor_mutates_rhs Pa

Re: [Boost-cmake] [wtf] /build /all modularizes your code on windows?

troy d. straszheim wrote: Juergen Hunold just mentioned on IRC that he'd used the commandline interface on windows to make '/build /all', and his code got 'modularized' (a word I'm beginning to hate) and significantly damaged. The problem is that "/all" builds all targets in the Visual Studio

Re: [Boost-cmake] target property LOCATION

troy d. straszheim wrote: This is documented as deprecated in cmake 2.6, but not so in 2.7.CVS. I think I need to get the absolute location of an executable so I can pass it to add_test. How should this be done? I think 2.6.4's documentation removed the word 'deprecated'. However, the LOCAT

Re: [Boost-cmake] link tests

troy d. straszheim wrote: 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: We generally build all test executables and libraries during the

Re: [Boost-cmake] Labels for known failures

Michael Jackson wrote: thanks for the heads up about vxl. I took those 2 scripts and adapted them for boost. I have since been able to submit an experimental Dashboard to . Look for f...@bluequartz.net - the one that actually ran all t

Re: [Boost-cmake] Labels for known failures

troy d. straszheim wrote: 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? The settings in the source tree are project-wide and have CDash submission information. These are shared by all subm

Re: [Boost-cmake] Labels for known failures

troy d. straszheim wrote: 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 c

Re: [Boost-cmake] placement_new test failure under VC++8

Doug Gregor wrote: That's very bad; CTest should be disabling this dialog, because this is going to happen often. Unless our tests are doing something to re-enable the dialog? We usually use _CrtSetReportHook: http://msdn.microsoft.com/en-us/library/0yysf5e6(VS.80).aspx in our tests to disa

Re: [Boost-cmake] Labels for known failures

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 o

Re: [Boost-cmake] Creating "Known Issues": CMake Problems with boost 1.39

Doug Gregor wrote: Basically, when you have both a shared and a static library "foo" in the same directory, CMake uses -lfoo and we'll pick up whatever the linker wants (the shared library). [snip] Other ideas for a fix to this problem would be helpful! I'm stumped. CMake 2.6 uses full paths

Re: [Boost-cmake] Wiki to disappear: docs in progress

Beman Dawes wrote: On Tue, May 12, 2009 at 4:38 PM, Doug Gregor wrote: Beman, did you enable testing? No. I figured that was a bit much for now. Even without all of the tests, Boost still has a huge number of targets in it. Yes, although I've been impressed with how fast everything excep

Re: [Boost-cmake] Wiki to disappear: docs in progress

Doug Gregor wrote: On Tue, May 12, 2009 at 1:02 PM, Beman Dawes wrote: I first tried to use the VC++ IDE compiler. The Solution file is so large it is impossibly slow to load and unload. A non-starter. Bill or Brad had warned about that, so no surprise, and I just moved on to the command line c

Re: [Boost-cmake] CDash dashboard now available

troy d. straszheim wrote: Doug Gregor wrote: This is a work in progress; we'll be working to make submission easier (e.g., via CTest scripts), get more testing working, and make use of some of the newer, cooler features of CDash that can help Boost... but we could certainly use more help! An

Re: [Boost-cmake] Analysis of the current CMake system

David Abrahams wrote: Click on Show Filters, and you can create a filter that shows only errors, warnings or other items that you want. The idea will be to be able to save the queries and create your own custom views for different purposes. Nice capability; not a great interface. If I want

Re: [Boost-cmake] Analysis of the current CMake system

troy d. straszheim wrote: Maybe I'm missing something... how do I tell what code has been compiled? By the build timestamp? CTest's submissions are broken into "Nightly", "Experimental", and "Continuous" categories. Look at a page like this: http://trilinos-dev.sandia.gov/cdash/index.php

Re: [Boost-cmake] Analysis of the current CMake system

Brad King wrote: The current CDash release will not understand CTest build submissions that use this launcher interface, so one would need CDash from its SVN trunk to try it. Sandia's Trilinos project is using CTest launchers with CDash from SVN trunk. Here is an example page showing e

Re: [Boost-cmake] Analysis of the current CMake system

troy d. straszheim wrote: So the first order of business would be to remove this kind of thing: set(CMAKE_CXX_COMPILE_OBJECT "\"${PYTHON_EXECUTABLE}\" \"${BOOST_TEST_DRIVER}\" cxx_compile_object ${CMAKE_CXX_COMPILE_OBJECT}" ) We're 100% agreed on the need for this, as far as I can see. A

Re: [Boost-cmake] Analysis of the current CMake system

o its output is recorded separately from other tests. Run-tests can use either #1 or #2. Compile-only tests should use #2 since the interesting part of the test is the compilation, and compile-fail tests can clearly not be linked to other tests. David Abrahams wrote: > on Thu Jan 15 2009, Brad Kin

Re: [Boost-cmake] Analysis of the current CMake system

troy d. straszheim wrote: > I don't quite get "That doesn't mean we can't test some tools without > log-scraping". > > I see two different cases here. There's the developer working under > visual studio or emacs who wants to run some tests. This guy knows (or > should know) how to find what comp

Re: [Boost-cmake] Analysis of the current CMake system

David Abrahams wrote: > * logfile scraping is too hopelessly fragile to make for a good testing > system, and there are better and possibly even easier alternatives. The question here is whether one wants to test with the same tools users might use to build the project. If one user's tool doesn

Re: [Boost-cmake] Analysis of the current CMake system

he 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. Great. I'll wait for your specific comments to continue discussion. > Brad King wrote: >> In summary, I&#x

[Boost-cmake] Analysis of the current CMake system

Hi Folks, I'm considering attending BoostCon 2009 to provide developer-level CMake expertise, and I'm looking into proposing a session as Hartmut requested. In preparation I've downloaded and tried the current system and read back through some of the discussion on this list: http://thread.gman