Hi all, I'm sitting here developing a build script to automate my build which first of all involves checking out sources, one of which is boost. However, 99.9% of the checkout time is boost tests/documentation/examples and what have you. It would be such a good feature to split out these stuffs so that there is a way to get to the nitty gritty jucy stuff without having to wait half a day... ;) Sorry for kicking in open doors, if that's what I'm doing ? :) Regards /Rob
Robert Bielik wrote:
Hi all,
I'm sitting here developing a build script to automate my build which first of all involves checking out sources, one of which is boost. However, 99.9% of the checkout time is boost tests/documentation/examples and what have you.
If it were me, I'd think a little more about this. When I include boost in a (real) commercial project. I include/link to a public directory which contains the release of boost I want to depend on. I don't check it out of some depostitory and re-build. I do this for a few reasons. a) It saves a lot of time. b) It prevents me from getting surprised by changes that I'm not expecting. c) It lets me change one thing at a time (corallory to b). When I've got nothing else to do or my app needs some new library/feature I can replace the boost version and re-run any testing. If there's any problem I can just redirect to the original spot until my complaints are addressed. Boost files are "read-only" in this context so they are not great candidates for "checking out the latest version" Robert Ramey
Robert Ramey skrev 2011-06-21 21:12:
If it were me, I'd think a little more about this. When I include boost in a (real) commercial project. I include/link to a public directory which contains the release of boost I want to depend on.
Neat, so there are such creatures publicly available ? Examples ? Also, I don't need all of boost, just some parts of it...
b) It prevents me from getting surprised by changes that I'm not expecting.
No problem for me as I use svn:external with specified revision...
Boost files are "read-only" in this context so they are not great candidates for "checking out the latest version"
That's not what I'm doing. The build script is for building everything within a project to eventually produce installer files, totally automated. /Rob
Robert Bielik wrote:
Robert Ramey skrev 2011-06-21 21:12:
If it were me, I'd think a little more about this. When I include boost in a (real) commercial project. I include/link to a public directory which contains the release of boost I want to depend on.
Neat, so there are such creatures publicly available ? Examples ? Also, I don't need all of boost, just some parts of it...
Also look into BCP which extracts a subset of boost libraries. I tried this, and much to my amazement - it worked well.
b) It prevents me from getting surprised by changes that I'm not expecting.
No problem for me as I use svn:external with specified revision...
Boost files are "read-only" in this context so they are not great candidates for "checking out the latest version"
That's not what I'm doing. The build script is for building everything within a project to eventually produce installer files, totally automated. /Rob
On Tue, Jun 21, 2011 at 12:04:11PM -0800, Robert Ramey wrote:
Robert Bielik wrote:
Robert Ramey skrev 2011-06-21 21:12:
If it were me, I'd think a little more about this. When I include boost in a (real) commercial project. I include/link to a public directory which contains the release of boost I want to depend on.
Neat, so there are such creatures publicly available ? Examples ? Also, I don't need all of boost, just some parts of it...
Also look into BCP which extracts a subset of boost libraries. I tried this, and much to my amazement - it worked well.
Your mileage may vary a lot, though. I had a case in #boost last month where an user tried extracting Boost.Bimap with bcp, which failed (reproducably) at pulling in sufficient amounts of MPL. This might be due to heavy Boost.PP usage. Don't forget to verify that your bcp'd things actually work. -- Lars Viklund | zao@acc.umu.se
On Tue, Jun 21, 2011 at 12:22 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Tue, Jun 21, 2011 at 12:04:11PM -0800, Robert Ramey wrote:
Robert Bielik wrote:
Robert Ramey skrev 2011-06-21 21:12:
If it were me, I'd think a little more about this. When I include boost in a (real) commercial project. I include/link to a public directory which contains the release of boost I want to depend on.
Neat, so there are such creatures publicly available ? Examples ? Also, I don't need all of boost, just some parts of it...
Also look into BCP which extracts a subset of boost libraries. I tried this, and much to my amazement - it worked well.
Your mileage may vary a lot, though.
I had a case in #boost last month where an user tried extracting Boost.Bimap with bcp, which failed (reproducably) at pulling in sufficient amounts of MPL. This might be due to heavy Boost.PP usage.
Yes, bcp does pulls in MPL, that's because it is very conservative, which is probably a good thing. At any rate, the resulting Boost is much smaller than the whole thing. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Jun 21, 2011 at 01:04:41PM -0700, Emil Dotchevski wrote:
On Tue, Jun 21, 2011 at 12:22 PM, Lars Viklund <zao@acc.umu.se> wrote:
Your mileage may vary a lot, though.
I had a case in #boost last month where an user tried extracting Boost.Bimap with bcp, which failed (reproducably) at pulling in sufficient amounts of MPL. This might be due to heavy Boost.PP usage.
Yes, bcp does pulls in MPL, that's because it is very conservative, which is probably a good thing. At any rate, the resulting Boost is much smaller than the whole thing.
Smaller, yes. Working, no. I wish there were caveats in the documentation describing these fatal flaws. Instead, it seems to pride itself on claiming it pulls in everything, whether it applies for your platform or not. -- Lars Viklund | zao@acc.umu.se
I had a case in #boost last month where an user tried extracting Boost.Bimap with bcp, which failed (reproducably) at pulling in sufficient amounts of MPL. This might be due to heavy Boost.PP usage.
Yes, bcp does pulls in MPL, that's because it is very conservative, which is probably a good thing. At any rate, the resulting Boost is much smaller than the whole thing.
Smaller, yes. Working, no.
I wish there were caveats in the documentation describing these fatal flaws. Instead, it seems to pride itself on claiming it pulls in everything, whether it applies for your platform or not.
Please file a bug report if there's a problem, otherwise I - probably - don't get to hear about it. Now that I have, I'll investigate Bimap, Regards, John.
On Wed, Jun 22, 2011 at 09:47:21AM +0100, John Maddock wrote:
I had a case in #boost last month where an user tried extracting Boost.Bimap with bcp, which failed (reproducably) at pulling in sufficient amounts of MPL. This might be due to heavy Boost.PP usage.
Yes, bcp does pulls in MPL, that's because it is very conservative, which is probably a good thing. At any rate, the resulting Boost is much smaller than the whole thing.
Smaller, yes. Working, no.
I wish there were caveats in the documentation describing these fatal flaws. Instead, it seems to pride itself on claiming it pulls in everything, whether it applies for your platform or not.
Please file a bug report if there's a problem, otherwise I - probably - don't get to hear about it.
Now that I have, I'll investigate Bimap,
I told the person to file a bug for it, which I do whenever someone discovers a problem, and was of the impression that he understood what I said. I guess I should have followed up by looking at the trac later. -- Lars Viklund | zao@acc.umu.se
I wish there were caveats in the documentation describing these fatal flaws. Instead, it seems to pride itself on claiming it pulls in everything, whether it applies for your platform or not.
Please file a bug report if there's a problem, otherwise I - probably - don't get to hear about it.
Now that I have, I'll investigate Bimap,
I told the person to file a bug for it, which I do whenever someone discovers a problem, and was of the impression that he understood what I said.
I guess I should have followed up by looking at the trac later.
Apologies for resurrecting this old thread, but I finally got around to looking into this, and couldn't reproduce the issue, I tried both: bcp bimap destination and all the bimap tests built OK for me, so then I tried: bcp boost/bimap.hpp destination and a trivial #include <boost/bimap.hpp> program also compiled fine. This is all with current Trunk BTW. So... unless there's some platform/compiler specific thing going on I'm stuck. Regards, John.
On Mon, Jul 11, 2011 at 04:39:54PM +0100, John Maddock wrote:
I wish there were caveats in the documentation describing these fatal flaws. Instead, it seems to pride itself on claiming it pulls in everything, whether it applies for your platform or not.
Please file a bug report if there's a problem, otherwise I - probably - don't get to hear about it.
Now that I have, I'll investigate Bimap,
I told the person to file a bug for it, which I do whenever someone discovers a problem, and was of the impression that he understood what I said.
I guess I should have followed up by looking at the trac later.
Apologies for resurrecting this old thread, but I finally got around to looking into this, and couldn't reproduce the issue, I tried both:
bcp bimap destination bcp boost/bimap.hpp destination
So... unless there's some platform/compiler specific thing going on I'm stuck.
I'm at a loss. None of the platforms I've tried now (msvc, debian gcc) fail with trunk. I can unfortunately not remember which platform/release it was I tested on, as none of the machines I currently have access to have any trace of bcp testing. I couldn't test mingw, as my installation of msysgit fails to compile fileview.cpp as it tries to call a non-existant std::ifstream(wchar_t const*). I guess that it's mentally closeable, unless the luser or I manage to coax something into breaking again. Sorry for the FUD. -- Lars Viklund | zao@acc.umu.se
On Mon, Jul 11, 2011 at 09:37:27PM +0200, Lars Viklund wrote:
On Mon, Jul 11, 2011 at 04:39:54PM +0100, John Maddock wrote:
So... unless there's some platform/compiler specific thing going on I'm stuck.
I'm at a loss. None of the platforms I've tried now (msvc, debian gcc) fail with trunk.
I can unfortunately not remember which platform/release it was I tested on, as none of the machines I currently have access to have any trace of bcp testing.
IRC logs seems to indicate that it was on Solaris with SunStudio, but I cannot get a proper build of bcp at all currently on any of my (x86/sparc) 5.9/5.10 compilers, where copy_file.o fails to build due to an ICE and a constant expression error in regex. I might have used some version other than the 1.44.0, 1.46.1 and current trunk, as none of those compile bcp at all. Anyway, the repro I achieved back then succeeded with a full tree but failed with a bcp'd tree, for some reason. -- Lars Viklund | zao@acc.umu.se
IRC logs seems to indicate that it was on Solaris with SunStudio, but I cannot get a proper build of bcp at all currently on any of my (x86/sparc) 5.9/5.10 compilers, where copy_file.o fails to build due to an ICE and a constant expression error in regex. I might have used some version other than the 1.44.0, 1.46.1 and current trunk, as none of those compile bcp at all.
Reproduced on Linux with Sun Studio 12.1. Unfortunately there are Boost.Filesystem failures as well as an internal compiler error: sun.compile.c++ /home/john/bin/boost/bin.v2/tools/bcp/sun-12.1/release/link-static/stdlib-sun-stlport/copy_path.o
Assertion: unexpected or unrecognized operator in err_operator (../lnk/tempactual.cc, line 384) while processing /home/john/SunStudio/sunstudio12.1/prod/include/CC/stlport4/stl/_string_io.c at line 0.
Anyway, the repro I achieved back then succeeded with a full tree but failed with a bcp'd tree, for some reason.
Can you tell me which files were missing (or at least what the errors were)? Using a gcc built bcp to copy boost/bimap.hpp I see the same Sun Studio error with both Trunk and the bcp'ed copy: "../trunk/boost/multi_index/indexed_by.hpp", line 56: Error: Type name expected instead of "BOOST_PP_ENUM_1". "../trunk/boost/multi_index/indexed_by.hpp", line 58: Error: Expected "class" or "typename" before "BOOST_MULTI_INDEX_INDEXED_BY_TEMPLATE_PARM" . "../trunk/boost/multi_index/indexed_by.hpp", line 58: Error: Type name expected instead of "T". 3 Error(s) detected. John.
Robert, greetings -- Robert Bielik <robert.bielik@xponaut.se> writes:
Also, I don't need all of boost, just some parts of it...
I've had good luck with automated scripts that: 1. Download the requested boost tarball (if it's not already present on the filesystem) 2. Unpack it 3. Build only the libraries that I use (or, at least, remove large libraries that I /don't/ use) 4. Install headers and libs to my project's "staging" area 5. Build my project against the staging area 6. Copy only libraries from boost (no headers) to the project's final "root" area. (This is for an embedded project, if you hadn't already guessed.) This gives me all the advantages that Robert Ramey mentions (reproducibility etc) as well as a smaller footprint: since I don't use python, wave, graph, math, etc, I simply exclude them at build time. My actual bjam invocation looks like so: export ZLIB_BINARY="z" export ZLIB_INCLUDE="$PLATFORM_STAGE"/include export ZLIB_LIBPATH="$PLATFORM_STAGE"/lib export BZIP2_BINARY="bz2" export BZIP2_INCLUDE="$PLATFORM_STAGE"/include export BZIP2_LIBPATH="$PLATFORM_STAGE"/lib # debug_conf="" debug_conf="--debug-configuration" log boost: building and installing PATH="$bx"/bin:$PATH \ "$bjam" --prefix="$PLATFORM_STAGE" \ --without-graph \ --without-graph_parallel \ --without-math \ --without-mpi \ --without-python \ --without-serialization \ --without-wave \ $MAKE_PARALLEL_ARGS \ $debug_conf \ link=shared \ runtime-link=shared \ install || exit $?
That's not what I'm doing. The build script is for building everything within a project to eventually produce installer files, totally automated.
Why not build from a release tarball, instead of pulling from SVN? Best regards, Tony
Hello Tony, Anthony Foiani skrev 2011-06-22 03:01:
Why not build from a release tarball, instead of pulling from SVN?
Yes, that has crossed my mind as I'd guess unpacking the tarball is _way_ faster than a svn checkout. I haven't just had the time to figure out how to fit that into my CMake workflow :) All the best, /Robert
Hi, Am 22.06.2011 07:58, schrieb Robert Bielik: [...]
I haven't just had the time to figure out how to fit that into my CMake workflow :)
I highly recommend the CMake macro ExternalProject_Add which is available IIRC from CMake 2.8.3 or 2.8.4. It is able to download, patch/update, configure, build and install projects that are not part of your actual CMake project. It defaults to configure/build this project with CMake, but you can even configure arbitrary commands for each step. I have a by bootstrap script that I currently use to checkout the repo, build external libraries from local or remote tarballs and pre-configure my _actual_ project. This is the important snippet that builds boost for me: IF( BUILD_BOOST ) IF( WIN32 ) SET( BOOTSTRAP_EXT "bat" ) ELSE() SET( BOOTSTRAP_EXT "sh" ) ENDIF() SET( Boost_LIBRARY_DIR "${REPO_DIR}/trunk/org/boost/1_44_0/lib" CACHE INTERNAL "") ExternalProject_Add( Boost URL ${Boost_URL} UPDATE_COMMAND "" BUILD_IN_SOURCE 1 CONFIGURE_COMMAND "./bootstrap.${BOOTSTRAP_EXT}" BUILD_COMMAND bjam --layout=tagged --without-mpi --without-python --prefix=${Boost_LIBRARY_DIR}/.. variant=release link=shared threading=multi runtime-link=shared install INSTALL_COMMAND "" ) ELSE() SET( Boost_LIBRARY_DIR "" CACHE INTERNAL "" FORCE) ENDIF() Let me know if you need more details. Best Johannes
participants (2)
-
Anthony Foiani -
Emil Dotchevski -
Johannes Stallkamp -
John Maddock -
Lars Viklund -
Robert Bielik -
Robert Ramey