Re: [Boost-cmake] Web hosting problems?

Luigi Calori wrote: I noticed that can not get to http://sodium.resophonic.com/ it's back, thanks for the heads-up. -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 writes: > 2009/12/21 Troy D. Straszheim > > AFAIK this is the only python module built by boost and nobody has given > serious thought to where it should be installed.  This is a large can of > wriggly worms.  /usr/lib[64]/python2.6/boost does sounds

Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly

Denis Arnaud writes: > 2009/11/4 troy d. straszheim > > 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 &#x

Re: [Boost-cmake] Another small issue with Boost.CMake and FindBoost.cmake

Michael Jackson 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/

Re: [Boost-cmake] Another small issue with Boost.CMake and FindBoost.cmake

Michael Jackson 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 n

Re: [Boost-cmake] Another small issue with Boost.CMake and FindBoost.cmake

Michael Jackson 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

Re: [Boost-cmake] Another small issue with Boost.CMake and FindBoost.cmake

Michael Jackson writes: > 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 b

[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: [CMa

Re: [Boost-cmake] boost 1.41.0-cmake0 and CMake 2.6.4 - The usual, CMake can not find boost.

Philip Lowman wrote: On Fri, Dec 4, 2009 at 6:06 PM, troy d. straszheim wrote: 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

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 a

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/Libr

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 tha

Re: [Boost-cmake] boost 1.41.0-cmake0 and CMake 2.6.4 - The usual, CMake can not find boost.

Michael Jackson wrote: Pulled the latest boost 1.41.0cmake0, compiled and installed. Then I tried to have my CMake based project find Boost. As usual, this failed. Using CMake 2.6.4 currently. Started debugging into the FindBoost.cmake file and here is what I am finding out: _boost_INCLUDE_S

Re: [Boost-cmake] Generation of the PDF file

Michael Jackson wrote: How is the PDF file 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 acknowledgem

Re: [Boost-cmake] Release 1.41.0.cmake0, RPM generator problem

Gordan Sikic wrote: Hi Arnaud, could you point us (at least me) on the RPM specification file you used? I didn't use any special rpm-spec file; it was generated during pacgkage generation. In particular, I made following: $ cmake-gui (select CPACK option to make RPM) $ make $ make pack

[Boost-cmake] Reporting bugs (please make tickets)

All, We're at the point where there are enough users and bugs/tweaks coming in that they're hard to keep track of, so please use trac: https://svn.boost.org/trac/boost/newticket So they don't get lost. Don't forget to select component 'CMake'. Thanks in advance. -t __

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 bui

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

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/b

Re: [Boost-cmake] Release 1.41.0.cmake0

Vladimir Prus wrote: troy d. straszheim wrote: Surya Kiran Gullapalli wrote: I'll have a look. Meanwhile, could you try specifying the paths with forwardslashes rather than backslashes? Thanks, It worked This behaviour is different from bjam. I'm not too concerned with do

Re: [Boost-cmake] Release 1.41.0.cmake0

Surya Kiran Gullapalli wrote: I'll have a look. Meanwhile, could you try specifying the paths with forwardslashes rather than backslashes? Thanks, It worked This behaviour is different from bjam. I'm not too concerned with doing things exactly as bjam does them. In the case of zlib/bzip2, w

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

Re: [Boost-cmake] Release 1.41.0.cmake0

James C. Sutherland wrote: On Nov 18, 2009, at 12:25 PM, troy d. straszheim wrote: 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

Re: [Boost-cmake] Release 1.41.0.cmake0

James C. Sutherland wrote: On Nov 18, 2009, at 12:25 PM, troy d. straszheim wrote: 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

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 "di

[Boost-cmake] Release 1.41.0.cmake0

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 ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boo

Re: [Boost-cmake] _SECURE_SCL

Thomas Klimpel wrote: Hi, When I build boost with bjam, I add _SECURE_SCL=0 to the command line when building the release libraries. (I have to do this, because this switch affects ABI compatibility) How do I do the same with the cmake-based build system? Regards, Thomas I've started a FAQ,

[Boost-cmake] git pull?

troy d. straszheim wrote: Biddiscombe, John A. wrote: Does anyone know why I'm not getting a dartconfiguration.tcl or equivalent in my build dir? Tests are there and running, but cmake is not picking up the drop site etc (also the DART timeout of 15 seconds is being ignored) Any

Re: [Boost-cmake] CDash for boost CMake (builds not appearing)

Biddiscombe, John A. wrote: Does anyone know why I'm not getting a dartconfiguration.tcl or equivalent in my build dir? Tests are there and running, but cmake is not picking up the drop site etc (also the DART timeout of 15 seconds is being ignored) Any ideas? Thanks JB I think I got it,

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

Re: [Boost-cmake] CDash for boost CMake (builds not appearing)

Biddiscombe, John A. wrote: > > beneficial to me would be a windows box and a mac; I have plenty of I have done a git pull and built boost from cmake. I have two problems 1) there were 2768 (or similar) tests which was just too much, so I have disabled static/debug and just left release/

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

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

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

[Boost-cmake] disabling particular external dependencies

Sean Chittenden wrote: 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 This reminds me. Is there anyway to disable building the python

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 m

[Boost-cmake] [1.41.0] the first beta of the first beta

The boost.cmake beta that shadows upstream releases is out. Docs: http://sodium.resophonic.com/boost-cmake/1.41.0.beta1.cmake1/doc Tarballs and zipfiles: http://sodium.resophonic.com/boost-cmake/1.41.0.beta1.cmake1 If you've been waiting around to try the cmake build, this is the time. -

Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly

Denis Arnaud wrote: 2009/11/3 troy d. straszheim <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

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 pack

Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly

#x27;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 Date: Sat Oct 31 21:37:53 20

Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly

Denis Arnaud wrote: Hello, as Troy mentioned (http://lists.boost.org/boost-cmake/2009/10/0740.php), the head of the 1.40.0 git branch allows generating the RPM packages for Fedora 11 on both 32 and 64bit platforms. Just for information, I have updated the change request on Bugzilla: https:/

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

Correction to the below: replace /usr/ (as in /usr/share) with ${CMAKE_INSTALL_PREFIX}/ Sorry for any confusion. -t troy d. straszheim wrote: Here's what I've got. There are several options controlling how things are built and installed, here are short descriptions: INSTALL

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

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'

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 c

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

[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:

Re: [Boost-cmake] RFC: exported targets

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 cluttering the library directory with .cmake files

Re: [Boost-cmake] RFC: exported targets

Ingmar Vanhassel wrote: Excerpts from troy d. straszheim's message of Thu Oct 29 21:03:01 +0100 2009: Brad King wrote: 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 librarie

Re: [Boost-cmake] RFC sonames initial implementation

Brad King wrote: If there is no interface version, there is no need for the soname to be different from the real binary name. IOW, we could just set VERSION=1.2 and no SOVERSION, and CMake will produce libfoo.so -> libfoo.so.1.2 # link to help static linker -lfoo flags libfoo.so.1.2

Re: [Boost-cmake] RFC: exported targets

Brad King wrote: 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 e

[Boost-cmake] FindBoost.cmake

Michael Jackson wrote: So the problem I see with this is that I still need to know "a priori" what boost libraries are available on the system so exporting the targets really doesn't help much, at least not me. In your example (quoted below) what happens if I don't have the shared-debug of bo

[Boost-cmake] RFC sonames initial implementation

Brad King wrote: Denis Arnaud wrote: 2009/10/28 Vladimir Prus mailto:vladi...@codesourcery.com>> 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 just check

[Boost-cmake] RFC: exported targets

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 problem, but it is easy. http://sodi

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

Denis Arnaud wrote: 2009/10/28 troy d. straszheim <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 packager

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 wou

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

Denis ARNAUD wrote: 2009/10/28 Denis ARNAUD > [...] 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)

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

Denis ARNAUD wrote: Hello, from what I understand by reading that thread (title: "**Re: [Boost-build] Help deciphering gcc.jam, please* *", in April 2004

[Boost-cmake] 1.41.0.cmakebeta4

Here's the latest on the 1.41 front: http://sodium.resophonic.com/boost-cmake/1.41.0.cmakebeta4/ That contains everything that I have in the queue, so new versions should now come out only in case of upstream updates or fixes/features from y'all. -t ___

[Boost-cmake] 1.40.0.cmake4

I've put up a 1.40.0.cmake4, containing features backported from the 1.41.0 beta. Hopefully this will be the last in the 1.40 series including LIB_SUFFIX and ways to tweak the python detection. 1.40.0.cmake3 has been skipped, that tag got into the wild accidentally. -t __

Re: [Boost-cmake] 1.41.0.cmakebeta3

Sean Chittenden wrote: What's the tarball's layout going to look like? Cmakebeta3 has a radically different structure to it compared to earlier releases. -sc Ouch. That's a bug in my new tarballing stuff, apparently I'm doing too many things at once. I'll repost shortly, thanks for the h

Re: [Boost-cmake] 1.41.0.cmakebeta3

Daniel James wrote: On Tue, Oct 27, 2009 at 6:03 PM, troy d. straszheim 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 a

[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.cm

[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/boos

Re: [Boost-cmake] [PATCH] Use LIB_SUFFIX, allows installing 64bit libs into /usr/lib64.

Sean Chittenden wrote: 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. Anything KDE-4 based supports this. kd

Re: [Boost-cmake] [PATCH] Use LIB_SUFFIX, allows installing 64bit libs into /usr/lib64.

Sean Chittenden wrote: Take: http://www.gnu.org/software/hello/manual/autoconf/Makefile-Substitutions.html#Makefile-Substitutions Your: http://www.gnu.org/software/hello/manual/autoconf/Installation-Directory-Variables.html#Installation-Directory-Variables Pick: http://www.gnu.org/softwar

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 l

Re: [Boost-cmake] [PATCH] Use LIB_SUFFIX, allows installing 64bit libs into /usr/lib64.

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

Re: [Boost-cmake] cmake 2.8 beta: item named 'ZERO_CHECK'

David Cole wrote: It's a CMake bug. It will be fixed in 2.8.0-rc4. Roger. Thanks a lot. -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

[Boost-cmake] cmake 2.8 beta: item named 'ZERO_CHECK'

Hey, I'm getting reports that the current 1.41.0 boost-cmake beta combined with the 2.8 cmake beta results in a zillion popups complaining about ZERO_CHECK. Can anyone verify? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lis

[Boost-cmake] 1.41.0.cmake-beta0: 98% passing tests

All - I've started a 1.41 branch from the current release branch and got things building on Ubuntu 9.04. The number of tweaks required was very low, apparently not much has changed since ... our first interest is of course just to get boost built and installed with our build tool of choice,

[Boost-cmake] 1.40.0.cmake2

There's a little patch release up. If you've got a working 1.40.0 you don't need it. * Disable old, confusing modularization target, replace with message explaining that it is not necessary to do any modularization * Various documentation tuneups, improved 'quickstart' Tarballs and zipfiles

Re: [Boost-cmake] Repository moving

troy d. straszheim wrote: Thomas Klimpel wrote: Hi Troy, I'm having trouble with the new repository (but I never tried the old one). The page says "Clone this repository (Git / HTTP) : git clone git://gitorious.org/boost/cmake.git" but after the repository is cloned, it com

Re: [Boost-cmake] Repository moving

Thomas Klimpel wrote: Hi Troy, I'm having trouble with the new repository (but I never tried the old one). The page says "Clone this repository (Git / HTTP) : git clone git://gitorious.org/boost/cmake.git" but after the repository is cloned, it complains "warning: remote HEAD refers to nonex

[Boost-cmake] Repository moving

The git repo for cmakeable boost is moving, to http://gitorious.org/boost/cmake so as to get my name out of the URLs. If you have clones, you can just update the paths in your .git/config. The new repo will be ready in a few hours. -t ___ Boo

[Boost-cmake] point release: boost-1.40.0.cmake1

A bugfix release is up, in tarball form here: http://sodium.resophonic.com/boost-cmake/ Corresponding to tag 1.40.0.cmake1 in this repository: http://gitorious.org/~straszheim/boost/cmake Brief release notes here: http://gitorious.org/~straszheim/boost/cmake/blobs/raw/1.40.0/tools/build/C

Re: [Boost-cmake] Issues with Intel C++

Justin Holewinski wrote: Nevermind the link errors, it was the dependency issue between inspect and Boost.System that you fixed in Friday's commit. I updated my local repository yesterday on Windows, but not on Mac. The compile error in Boost.Wave just needs the following fix (in /boost/wa

Re: [Boost-cmake] CMakeLists.txt references missing Boost.Thread files

Belcourt, Kenneth wrote: Hi, The CMakeLists.txt file in libs/thread/src references exceptions.cpp in both pthread and win32 subdirectories, but neither of these files exist. I've removed the reference to both of these and would appreciate it if someone could commit this patch to Subversion (

Re: [Boost-cmake] Issues with Intel C++

Justin Holewinski wrote: After fixing that, the build is successful with both Intel C++ and Visual Studio 9. Ah that was a dumb error. Thanks for the fix. I'm still looking into the link errors on Mac and Linux with Intel C++. I've got intel for linux... I don't see any link errors

Re: [Boost-cmake] Issues with Intel C++

Justin Holewinski wrote: Yes, I'm using your 1.40.0 distribution from gitorious.org . I downloaded it about a week ago, so it does not include the October 8 commits. I'll try the latest revision today sometime. Has the CMake build system been tested with CMake 2.8/2.9?

Re: [Boost-cmake] Issues with Intel C++

Justin Holewinski wrote: Thanks! The dependency error is fixed on Windows with the latest nightly binary. However, this version of CMake seems to break the Boost install target. Running "make install" results in errors from not finding libs/preprocessor/include/boost in the source tree, wh

Re: [Boost-cmake] Issues with Intel C++

Philip Lowman wrote: Hi, I can fix this in CVS, but might have a slightly better way. Can you tell me what the value of CMAKE_CXX_COMPILER_ID is on Intel C++? I pushed the recommended change to the 1.40.0 branch in git, will make another bugfix release if we can get these strange intel (

Re: [Boost-cmake] Possible linker error

motes motes wrote: I am trying to build an application using boost with CMake on Ubuntu 9.04. This is the content of my CMakeList.txt file: IF(Boost_unit_test_framework_LIBRARY) I think it'd be easier to emulate the way some of the other libraries do it using the unit test framework. See fo

[Boost-cmake] boost-1.40.0.cmake0.tar.gz tarball

John Biddiscombe wrote: troy Here is the direct download link for the cmake/1.40.0 branch, http://gitorious.org/boost/cmake/archive-tarball/1.40.0 I tried this several times over the last week or so and it only ever gives The archive is currently being generated, try again later Is there

Re: [Boost-cmake] First time build of boost-1.40.0 with cmake

John Murdie wrote: troy d. straszheim wrote I'm pretty sure the patches you need (and you don't need to make 'modularize') are on the 'official cmake' branch here: http://gitorious.org/~straszheim/boost/cmake/ Here is the direct download link for the cm

Re: [Boost-cmake] First time build of boost-1.40.0 with cmake

John Murdie wrote: I'd link all .hpp files I could find to /usr/local/include64/boost/*/ (as appropriate) and add: -DRELEASE_COMPILE_FLAGS="-O3 -DNDEBUG -I/usr/local/include64" to the cmake arguments, but there must be an easier way of preventing this problem, surely? I'm pretty sure the pa

Re: [Boost-cmake] [PATCH] building Boost.Python fails

Bill Hoffman wrote: So, at boost con we talked about setting up CDash for Boost. I think it would be much easier to maintain the CMake files for Boost if such a testing system were in place. I definitely agree. -t ___ Boost-cmake mailing list

Re: [Boost-cmake] [PATCH] building Boost.Python fails

Ingmar Vanhassel wrote: Excerpts from troy d. straszheim's message of Wed Sep 16 17:08:44 +0200 2009: Thanks for the patches. I tested and pushed to 1.40.0 branch of cmake repo. -t Will these patches land in boost SVN & its next release too? Well, there was some discussion about this over

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 p

Re: [Boost-cmake] cmake regression for 1.40 vs. 1.39...

Ingmar Vanhassel wrote: 'make DESTDIR=/foo install' is broken here: -- Installing: /home/ingmar/development/git/boost/DESTDIR/usr/local/include//boost/assign/std/slist.hpp -- Installing: /home/ingmar/development/git/boost/DESTDIR/usr/local/include//boost/assign/list_of.hpp -- Installing: /ho

Re: [Boost-cmake] cmake regression for 1.40 vs. 1.39...

Sean Chittenden wrote: Hello. I'm trying to use 1.40 in a fresh dev environment using cmake and am having significant difficulties getting it to work. 1.39 works flawlessly with cmake, but 1.40 not so much. I've had to manually edit Makefiles and .cmake files to include various include_

Re: [Boost-cmake] CMakeLists.txt missing copyright and licence

Beman Dawes wrote: This is causing lots of inspect failures. See http://boost.cowic.de/rc/inspect-trunk.html I'd like to see these cleared ASAP so I can pester developers about their real inspect problems during the bug sprint. Since some of these files are generated automatically, the genera

Re: [Boost-cmake] [boost] trunk vs release (qtsync implementation)

Ilya Sokolov wrote: troy d. straszheim wrote: 1. if you add or remove headers you'd have to rerun this script. 2. there's an extra #include hop in every error/warning. We could probably do something with links on unix to get around this. 3. it requires python It should be po

Re: [Boost-cmake] [boost] trunk vs release (qtsync implementation)

troy d. straszheim wrote: Juergen Hunold wrote: Maybe we should do it like Qt. I 'modularized' the release branch and implemented include-directory-generation with a python script. (see the post in this thread with 'qtsync' in the title) You can get a tarball of th

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

Brad King wrote: 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

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

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. This was on the trunk. Can anybody verify this? On unix, target 'all' doesn't make install

[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 testi

[Boost-cmake] target property LOCATION

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? -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org

Re: [Boost-cmake] Path to test binaries for Boost.MPI (and Boost.graph_parallel) seems to be incorrect

Beman Dawes wrote: On Wed, May 20, 2009 at 4:47 PM, troy d. straszheim wrote: Nick Edmonds wrote: Hi All, I've been hacking the CMake build system to build the tests/examples for libs/graph_parallel and in doing so found that the path to the tests seems to be incorrect. are you o

Re: [Boost-cmake] Path to test binaries for Boost.MPI (and Boost.graph_parallel) seems to be incorrect

Nick Edmonds wrote: Hi All, I've been hacking the CMake build system to build the tests/examples for libs/graph_parallel and in doing so found that the path to the tests seems to be incorrect. are you on the release branch? The trunk is currently lagging. If you want to just check in w

  1   2   >