"I want everything" should build "out of the box" (on Windows)
Users on Microsoft Windows should be able to build boost with everything, both in terms of all supported variants and all boost libraries, with a single command to bjam assuming they have all the optional supporting libraries available. An user download boost, and want to build all the libraries that require building go read the Getting Started Guide <.../getting_started/windows.html#invoke-bjam> and see the after getting bjam they use the command bjam --build-dir=build-directory toolset=toolset-name --build-type=complete stage So they enter that into the command prompt and see lots of warnings and notes about missing optional components. The warnings and notes itself is fine and informative. Actually, it's incomplete as it stand as it doesn't tell the user about Boost.IOStreams optional component requirement of bzip2 & zlib headers. Okay, the user go and install all the optional components the warnings and notes tell them. After installing Python, ICU (building it first), Expat (building it first), and MPI (say MS-MPI), they try again. This time with the command becoming bjam --toolset=... --build-dir=... --build-type=complete -sHAVE_ICU=1 -sICU_PATH="..." -sEXPAT_INCLUDE="..." -sEXPAT_LIBPATH="..." -sBZIP2_SOURCE="..." -sZLIB_SOURCE="..." stage Nope, MPI requires modification of user-config.jam or building it on its own with --with-mpi. Why? No other optional components build that way. So they look to see how they do that, and does it. Second attempt and ... nope. New to 1.39 is the errors error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use due to the changes made as a result of <http://lists.boost.org/Archives/boost/2009/04/150675.php>. (Recently noted on <http://groups.google.com/group/boost-list/browse_thread/thread/2a7bd07468b5ffe6>.) While catching those errors is good, maybe it should be fixed as well such that it doesn't come up in the first place if someone do a --build-type=complete with ICU. So now the users have to build Boost.Regex separately from the rest of the library (after finding how to pass the link= & runtime-link= options). By the way, at this point I would like to point out how it's strange that -sHAVE_ICU=1 mean to build with ICU, but so is -sHAVE_ICU=0 .... :S And ... nope, even separately Boost.Regex still wouldn't build without errors. No one told them they need to rename icuin.lib, icuind.lib, icuind.pdb & icudt.lib from ICU to icui18n.lib, icui18nd.lib, icui18nd.pdb & icudata.lib respectively. With Boost.Regex built, we turn to the rest of the library with --without-regex. After waiting a while, we discover ... nope, Most of the library is built but not Boost.Graph. Sorry, this time no one told them they need to change Boost.Graph's Jamfile.v2 file with "<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and adding "<define>XML_STATIC". Boost is great, it's free, it's flexible and I understand it's developed for free by volunteers, but its "installation" for someone that want every libraries could be improved. :-) Regards, KTC -- Only two things are infinite, the Universe and Stupidity. And I'm not quite sure about the former. - Albert Einstein
On Mon, Jul 27, 2009 at 11:51 PM, KTC<ktc@ktchan.info> wrote:
Users on Microsoft Windows should be able to build boost with everything, both in terms of all supported variants and all boost libraries, with a single command to bjam assuming they have all the optional supporting libraries available.
An user download boost, and want to build all the libraries that require building go read the Getting Started Guide <.../getting_started/windows.html#invoke-bjam> and see the after getting bjam they use the command bjam --build-dir=build-directory toolset=toolset-name --build-type=complete stage
So they enter that into the command prompt and see lots of warnings and notes about missing optional components. The warnings and notes itself is fine and informative. Actually, it's incomplete as it stand as it doesn't tell the user about Boost.IOStreams optional component requirement of bzip2 & zlib headers. Okay, the user go and install all the optional components the warnings and notes tell them. After installing Python, ICU (building it first), Expat (building it first), and MPI (say MS-MPI), they try again. This time with the command becoming bjam --toolset=... --build-dir=... --build-type=complete -sHAVE_ICU=1 -sICU_PATH="..." -sEXPAT_INCLUDE="..." -sEXPAT_LIBPATH="..." -sBZIP2_SOURCE="..." -sZLIB_SOURCE="..." stage
Nope, MPI requires modification of user-config.jam or building it on its own with --with-mpi. Why? No other optional components build that way. So they look to see how they do that, and does it.
Second attempt and ... nope. New to 1.39 is the errors error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use due to the changes made as a result of <http://lists.boost.org/Archives/boost/2009/04/150675.php>. (Recently noted on <http://groups.google.com/group/boost-list/browse_thread/thread/2a7bd07468b5ffe6>.) While catching those errors is good, maybe it should be fixed as well such that it doesn't come up in the first place if someone do a --build-type=complete with ICU. So now the users have to build Boost.Regex separately from the rest of the library (after finding how to pass the link= & runtime-link= options). By the way, at this point I would like to point out how it's strange that -sHAVE_ICU=1 mean to build with ICU, but so is -sHAVE_ICU=0 .... :S
And ... nope, even separately Boost.Regex still wouldn't build without errors. No one told them they need to rename icuin.lib, icuind.lib, icuind.pdb & icudt.lib from ICU to icui18n.lib, icui18nd.lib, icui18nd.pdb & icudata.lib respectively.
With Boost.Regex built, we turn to the rest of the library with --without-regex. After waiting a while, we discover ... nope, Most of the library is built but not Boost.Graph. Sorry, this time no one told them they need to change Boost.Graph's Jamfile.v2 file with "<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and adding "<define>XML_STATIC".
Boost is great, it's free, it's flexible and I understand it's developed for free by volunteers, but its "installation" for someone that want every libraries could be improved. :-)
As direct as all this was, I have to say that I have experienced *everything* he has, and more. The .bat file I have for building boost is getting rather large with all the stuff I have it do just to work-around so many things. I have mentioned a few of those on the boost lists, multiple times actually, but nothing has come from it. The build system definitely needs to be cleaned up a bit though, or at least made more consistent. That Boost.Regex and ICU annoyances took a bit of time to figure out when I first experienced each of those errors, and the odd thing, those errors have been propagating through many version now, and new ones seem to keep popping up, many of which I have talked about on this list, how to fix it, why it should be fixed, but no one that has commit privileges has yet done anything.
That Boost.Regex and ICU annoyances took a bit of time to figure out when I first experienced each of those errors, and the odd thing, those errors have been propagating through many version now, and new ones seem to keep popping up, many of which I have talked about on this list, how to fix it, why it should be fixed, but no one that has commit privileges has yet done anything.
Sorry I must have missed that, what's the problem/fix? Thanks for your patience.... Still catching up yours, John.
On Tue, Jul 28, 2009 at 3:37 AM, John Maddock<john@johnmaddock.co.uk> wrote:
That Boost.Regex and ICU annoyances took a bit of time to figure out when I first experienced each of those errors, and the odd thing, those errors have been propagating through many version now, and new ones seem to keep popping up, many of which I have talked about on this list, how to fix it, why it should be fixed, but no one that has commit privileges has yet done anything.
Sorry I must have missed that, what's the problem/fix?
The "error: link=shared together with runtime-link=static is not allowed" problem is the newest problem I have, appeared in recent versions, prevents us from doing a complete build. The ICU renaming thing, well, <quick google search>, Ooo, looky, the 2nd result (1st is the Boost.Regex docs) is one of my old (well, the most recent one) posts on this exact subject on the boost-users mailing list. :) http://lists.boost.org/boost-users/2008/12/43214.php I have made much older posts as well, but google cannot find them it seems... But yea, ICU version 3 (and they are *well* past that now, version 3 is really old now) changed the naming convention of their shared libraries, thus Boost does not link with it without renaming things. Check that post for what they were.
Sorry I must have missed that, what's the problem/fix?
The "error: link=shared together with runtime-link=static is not allowed" problem is the newest problem I have, appeared in recent versions, prevents us from doing a complete build.
You simply can not mix dll's with the static runtime - doing so will in almost all circumstances cause your application to crash.
The ICU renaming thing, well, <quick google search>, Ooo, looky, the 2nd result (1st is the Boost.Regex docs) is one of my old (well, the most recent one) posts on this exact subject on the boost-users mailing list. :) http://lists.boost.org/boost-users/2008/12/43214.php I have made much older posts as well, but google cannot find them it seems... But yea, ICU version 3 (and they are *well* past that now, version 3 is really old now) changed the naming convention of their shared libraries, thus Boost does not link with it without renaming things. Check that post for what they were.
Well... As of ICU-4.2, the names of the libraries are documented here: http://userguide.icu-project.org/icufaq#TOC-How-do-I-install-the-binary-vers... and match what the Jamfile assumes (and what I downloaded in the binary package), this information: http://source.icu-project.org/repos/icu/icu/tags/release-4-2-1/readme.html#H... also uses the same filenames, for example icuin.lib/dll and not icui18n.lib/dll. Still missing something yours, John.
On Wed, Jul 29, 2009 at 4:32 AM, John Maddock<john@johnmaddock.co.uk> wrote:
Sorry I must have missed that, what's the problem/fix?
The "error: link=shared together with runtime-link=static is not allowed" problem is the newest problem I have, appeared in recent versions, prevents us from doing a complete build.
You simply can not mix dll's with the static runtime - doing so will in almost all circumstances cause your application to crash.
The ICU renaming thing, well, <quick google search>, Ooo, looky, the 2nd result (1st is the Boost.Regex docs) is one of my old (well, the most recent one) posts on this exact subject on the boost-users mailing list. :) http://lists.boost.org/boost-users/2008/12/43214.php I have made much older posts as well, but google cannot find them it seems... But yea, ICU version 3 (and they are *well* past that now, version 3 is really old now) changed the naming convention of their shared libraries, thus Boost does not link with it without renaming things. Check that post for what they were.
Well... As of ICU-4.2, the names of the libraries are documented here: http://userguide.icu-project.org/icufaq#TOC-How-do-I-install-the-binary-vers... and match what the Jamfile assumes (and what I downloaded in the binary package), this information: http://source.icu-project.org/repos/icu/icu/tags/release-4-2-1/readme.html#H... also uses the same filenames, for example icuin.lib/dll and not icui18n.lib/dll.
The version of ICU I have is icu4c-3_8-src.zip, so I am not sure if that is version 4, or 3.8, or what... Let me hunt for a readme, ah, so it is 3.8. Well, in the windows version at least of 3.8, the libraries had those different names. I apparently last built that on October 18th, 2007, so yea, a bit old by now. I will rebuild with the latest ICU soon to verify the names are correct again.
On Wed, Jul 29, 2009 at 5:16 AM, OvermindDL1<overminddl1@gmail.com> wrote:
The version of ICU I have is icu4c-3_8-src.zip, so I am not sure if that is version 4, or 3.8, or what... Let me hunt for a readme, ah, so it is 3.8. Well, in the windows version at least of 3.8, the libraries had those different names. I apparently last built that on October 18th, 2007, so yea, a bit old by now. I will rebuild with the latest ICU soon to verify the names are correct again.
Er, correction, that was my old directory in a backup area, the version I am using right now is 4.0, last compiled on 12/12/08, so it still had those different names. I will try the latest however.
On Wed, Jul 29, 2009 at 5:17 AM, OvermindDL1<overminddl1@gmail.com> wrote:
On Wed, Jul 29, 2009 at 5:16 AM, OvermindDL1<overminddl1@gmail.com> wrote:
The version of ICU I have is icu4c-3_8-src.zip, so I am not sure if that is version 4, or 3.8, or what... Let me hunt for a readme, ah, so it is 3.8. Well, in the windows version at least of 3.8, the libraries had those different names. I apparently last built that on October 18th, 2007, so yea, a bit old by now. I will rebuild with the latest ICU soon to verify the names are correct again.
Er, correction, that was my old directory in a backup area, the version I am using right now is 4.0, last compiled on 12/12/08, so it still had those different names. I will try the latest however.
Okay, so I downloaded the latest 4.2.1, here are all the libs it dumped into the lib directory: icudt.lib icuin.lib icuind.lib icuio.lib icuiod.lib icule.lib iculed.lib iculx.lib iculxd.lib icutest.lib icutestd.lib icutu.lib icutud.lib icuuc.lib icuucd.lib So it looks like it is fixed now. But on my old versions, they build files with 18 in the name, I checked the solutions and they still do. Well, that problem no longer exists then, but I did battle with it for over 2 years there. :p
So it looks like it is fixed now. But on my old versions, they build files with 18 in the name, I checked the solutions and they still do.
If you can give me a list of the alternative names, I can (probably/hopefully!) add them to the names that get searched for. John.
On Wed, Jul 29, 2009 at 6:08 AM, John Maddock<john@johnmaddock.co.uk> wrote:
So it looks like it is fixed now. But on my old versions, they build files with 18 in the name, I checked the solutions and they still do.
If you can give me a list of the alternative names, I can (probably/hopefully!) add them to the names that get searched for.
John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I looked through the old solution and it looks like it is just these two: icui18n.lib icui18nd.lib The original files they reference are the same name, but no 18 in it.
There is a restriction that shared and static versions of libunit_test_framework are not interchangeable. This makes it difficult to ship unit tests since the author of a unit test cannot predict what type of libunit_test_framework (shared or static) the user has on their machine. Are there plans to get rid of this restriction? BR, Dmitry
Dmitry Goncharov wrote:
There is a restriction that shared and static versions of libunit_test_framework are not interchangeable. This makes it difficult to ship unit tests since the author of a unit test cannot predict what type of libunit_test_framework (shared or static) the user has on their machine.
1. This subject is discussed in length. Boost.Test opted for portability in between platform, instead of interchangeability between static and shared libraries. This is not a restriction, this is feature ;) 2. Am I to understand that you are library developer who ships unit tests along with library? 3. If answer is yes, do you ship your own makefiles? if yes, you can enforce specific library there. 4. If not, you can use single header variant of UTF and do not depend on library at all. It's not like your users are going to build your test modules over and over. 5. Your last option if none of the above fits is to make notes in documentation ;) Gennadiy
Thanks for your reply, Gennadiy Rozental wrote:
1. This subject is discussed in length. Boost.Test opted for portability in between platform, instead of interchangeability between static and shared libraries. This is not a restriction, this is feature ;) Can't really see how interchangeability between static and shared libraries prevents portability between platforms. Anyway, from your answer i understand that it is going to stay this way.
2. Am I to understand that you are library developer who ships unit tests along with library? That's right.
3. If answer is yes, do you ship your own makefiles? yes if yes, you can enforce specific library there. It is possible to enforce a specific library. It's also uncomfortable for the user.
4. If not, you can use single header variant of UTF and do not depend on library at all. That's right. This will increase compilation time.
It's not like your users are going to build your test modules over and over. That's right, the users aren't going to build test modules over an over. The developer (e.g. me) builds tests modules over and over.
5. Your last option if none of the above fits is to make notes in documentation ;)
Gennadiy
BR, Dmitry
Dmitry Goncharov <dgoncharov <at> unison.com> writes:
Thanks for your reply,
Gennadiy Rozental wrote:
1. This subject is discussed in length. Boost.Test opted for portability in between platform, instead of interchangeability between static and shared libraries. This is not a restriction, this is feature ;) Can't really see how interchangeability between static and shared libraries prevents portability between platforms.
The problem is that main function can't reside inside the shared library (at least not if portability is a concern), but it can inside the static one. Later was a default which we wanted to continue to employ. To properly support shared library usage variant I had to go with a bit different support scheme, with main function outside. Thus we came to the current state of affairs.
3. If answer is yes, do you ship your own makefiles? yes if yes, you can enforce specific library there. It is possible to enforce a specific library. It's also uncomfortable for the user.
How? I believe you only need to add -static in proper place in command line.
4. If not, you can use single header variant of UTF and do not depend on library at all. That's right. This will increase compilation time.
It's not like your users are going to build your test modules over and over. That's right, the users aren't going to build test modules over an over. The developer (e.g. me) builds tests modules over and over.
It should be trivial to have makefiles/test modules to support both variants, so that you will use shared library, and your users will use single header variant. Gennadiy
Gennadiy Rozental wrote:
The problem is that main function can't reside inside the shared library (at least not if portability is a concern), but it can inside the static one. Later was a default which we wanted to continue to employ. To properly support shared library usage variant I had to go with a bit different support scheme, with main function outside. Thus we came to the current state of affairs.
It is possible to have function main() in a dedicated library, not in libboost_unit_test_framework. In this case users who don't want to implement main() can link against that dedicated library. This lets static and dynamic libboost_unit_test_framework libraries be interchangeable. BR, Dmitry
Dmitry Goncharov <dgoncharov <at> unison.com> writes:
It is possible to have function main() in a dedicated library, not in libboost_unit_test_framework. In this case users who don't want to implement main() can link against that dedicated library. This lets static and dynamic libboost_unit_test_framework libraries be interchangeable.
There is also such thing as backward compatibility. Don't you think users who currently use static library variant of UTF would complain if all their test would start failing linking? There is an option already to have static library without main BOOST_TEST_NO_MAIN, but it had to be used when library is built. Gennadiy
Gennadiy Rozental wrote:
There is also such thing as backward compatibility. Don't you think users who currently use static library variant of UTF would complain if all their test would start failing linking?
I am not expecting anybody to break backward compatibility now. This just one solution that could have been implemented and it wasn't for some reason. I'm not sure that solution is worthy since it increases complexity. IMHO, the correct solution is to always have main() in the unit test and never have it in a library. I started this thread to find out what caused this uncomfortable situation about static and dynamic libraries. From you answers its clear that the situation is this just because it has been this way from the beginning.
There is an option already to have static library without main BOOST_TEST_NO_MAIN, but it had to be used when library is built.
Thanks for your help. BR, Dmitry
Dmitry Goncharov wrote:
Gennadiy Rozental wrote:
There is also such thing as backward compatibility. Don't you think users who currently use static library variant of UTF would complain if all their test would start failing linking?
I am not expecting anybody to break backward compatibility now. This just one solution that could have been implemented and it wasn't for some reason.
Originally the Boost.Test only supported static library. The main was included to minimize the effort developer need to apply to write simple est test module. It's still valid point. Unfortunately though we can't do it with shared lib. Also some users (like you) prefer to have their own entry point.
I'm not sure that solution is worthy since it increases complexity.
It does. And it's not acceptable IMO.
IMHO, the correct solution is to always have main() in the unit test and never have it in a library.
IMO it's not correct to force 95% of the users to write trivial main.
I started this thread to find out what caused this uncomfortable situation about static and dynamic libraries.
IMO it's uncomfortable for small percent of users (in very particular combination of conditions). And if then, solution always exists.
From you answers its clear that the situation is this just because it has been this way from the beginning.
I guess. And I still believe it's good compromise for most users. Gennadiy
John Maddock wrote:
Sorry I must have missed that, what's the problem/fix?
The "error: link=shared together with runtime-link=static is not allowed" problem is the newest problem I have, appeared in recent versions, prevents us from doing a complete build.
You simply can not mix dll's with the static runtime - doing so will in almost all circumstances cause your application to crash.
My complaint here wasn't that this was fixed, but rather that I think someone should be able to do a --build-type=complete and have all the supported variant of the libraries built. In the case of with ICU it would only build the shared versions. It shouldn't still try to build both when building with ICU thus causing the error and not building anything at all.
Well... As of ICU-4.2, the names of the libraries are documented here: http://userguide.icu-project.org/icufaq#TOC-How-do-I-install-the-binary-vers... and match what the Jamfile assumes (and what I downloaded in the binary package), this information: http://source.icu-project.org/repos/icu/icu/tags/release-4-2-1/readme.html#H... also uses the same filenames, for example icuin.lib/dll and not icui18n.lib/dll.
Um, the problem isn't that the build system wanted icuin and got given icui18n etc, it's the other way round. It wants icu18n & icudata, and is given icuin & icudt instead. if $(HAVE_ICU) { gHAS_ICU = true ; gICU_CORE_LIB = icuuc ; gICU_IN_LIB = icui18n ; gICU_DATA_LIB = icudata ; gICU_CONFIG_CHECKED = true ; } The else if clause right below that is kinda complicated and I'm not entirely following it, but it seems the build system is following two different path both building with ICU when ICU_PATH is set depending on whether HAVE_ICU is set. (My reading of the documentation suggest setting -sHAVE_ICU=1 to build with ICU.) As a test, I just downloaded the latest ICU 4.2 binary on Windows with VC9 and attempting to build using trunk, setting -sHAVE_ICU=1 -sICU_PATH="...". ...failed updating 5 targets... ...skipped 6 targets... ...updated 47 targets... When only ICU_PATH is set, it builds fine. ...updated 58 targets... KTC -- Only two things are infinite, the Universe and Stupidity. And I'm not quite sure about the former. - Albert Einstein
AMDG KTC wrote:
John Maddock wrote:
Sorry I must have missed that, what's the problem/fix?
The "error: link=shared together with runtime-link=static is not allowed" problem is the newest problem I have, appeared in recent versions, prevents us from doing a complete build.
You simply can not mix dll's with the static runtime - doing so will in almost all circumstances cause your application to crash.
My complaint here wasn't that this was fixed, but rather that I think someone should be able to do a --build-type=complete and have all the supported variant of the libraries built. In the case of with ICU it would only build the shared versions. It shouldn't still try to build both when building with ICU thus causing the error and not building anything at all.
I agree. The old behavior was to disable targets that used this bad combination instead of issuing an error. The error message is mostly useful, but causes problems in this particular case. In Christ, Steven Watanabe
On Wed, Jul 29, 2009 at 3:06 PM, KTC<ktc@ktchan.info> wrote:
Well... As of ICU-4.2, the names of the libraries are documented here: http://userguide.icu-project.org/icufaq#TOC-How-do-I-install-the-binary-vers... and match what the Jamfile assumes (and what I downloaded in the binary package), this information: http://source.icu-project.org/repos/icu/icu/tags/release-4-2-1/readme.html#H... also uses the same filenames, for example icuin.lib/dll and not icui18n.lib/dll.
Um, the problem isn't that the build system wanted icuin and got given icui18n etc, it's the other way round. It wants icu18n & icudata, and is given icuin & icudt instead. if $(HAVE_ICU) { gHAS_ICU = true ; gICU_CORE_LIB = icuuc ; gICU_IN_LIB = icui18n ; gICU_DATA_LIB = icudata ; gICU_CONFIG_CHECKED = true ; }
The else if clause right below that is kinda complicated and I'm not entirely following it, but it seems the build system is following two different path both building with ICU when ICU_PATH is set depending on whether HAVE_ICU is set. (My reading of the documentation suggest setting -sHAVE_ICU=1 to build with ICU.)
As a test, I just downloaded the latest ICU 4.2 binary on Windows with VC9 and attempting to build using trunk, setting -sHAVE_ICU=1 -sICU_PATH="...". ...failed updating 5 targets... ...skipped 6 targets... ...updated 47 targets... When only ICU_PATH is set, it builds fine. ...updated 58 targets...
Ah, in that case my very old solution I looked at had the correct names (maybe I changed them in the solution instead of just renaming the files), and the new solution still uses the new naming convention, hence Boost needs to be updated.
Well... As of ICU-4.2, the names of the libraries are documented here: http://userguide.icu-project.org/icufaq#TOC-How-do-I-install-the-binary-vers... and match what the Jamfile assumes (and what I downloaded in the binary package), this information: http://source.icu-project.org/repos/icu/icu/tags/release-4-2-1/readme.html#H... also uses the same filenames, for example icuin.lib/dll and not icui18n.lib/dll.
Um, the problem isn't that the build system wanted icuin and got given icui18n etc, it's the other way round. It wants icu18n & icudata, and is given icuin & icudt instead. if $(HAVE_ICU) { gHAS_ICU = true ; gICU_CORE_LIB = icuuc ; gICU_IN_LIB = icui18n ; gICU_DATA_LIB = icudata ; gICU_CONFIG_CHECKED = true ; }
The else if clause right below that is kinda complicated and I'm not entirely following it, but it seems the build system is following two different path both building with ICU when ICU_PATH is set depending on whether HAVE_ICU is set. (My reading of the documentation suggest setting -sHAVE_ICU=1 to build with ICU.)
As a test, I just downloaded the latest ICU 4.2 binary on Windows with VC9 and attempting to build using trunk, setting -sHAVE_ICU=1 -sICU_PATH="...". ...failed updating 5 targets... ...skipped 6 targets... ...updated 47 targets... When only ICU_PATH is set, it builds fine. ...updated 58 targets...
OK I'll look into that some more: however the intension was that HAVE_ICU and ICU_PATH should not be mixed, HAVE_ICU is designed for Unix like systems that have the icu binaries installed in the usual std locations under the std Unix naming convention for ICU. I'll try and tweak the logic so that ICU_PATH takes precedence in that case. Thanks, John.
On Tue, 28 Jul 2009 07:51:36 +0200, KTC <ktc@ktchan.info> wrote:
[...]the library is built but not Boost.Graph. Sorry, this time no one told them they need to change Boost.Graph's Jamfile.v2 file with "<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and adding "<define>XML_STATIC".
I have another question: What exactly does <find-shared-library> do? Does it automatically define and use a lib target like: lib xy : : <name>xy <link>shared ; Once I know what it does I'll add it to the feature reference at http://www.highscore.de/cpp/boostbuild/index.html#feature_reference (another attempt to make using bjam and Boost.Build a bit easier). Boris
Boris Schaeling wrote:
On Tue, 28 Jul 2009 07:51:36 +0200, KTC <ktc@ktchan.info> wrote:
[...]the library is built but not Boost.Graph. Sorry, this time no one told them they need to change Boost.Graph's Jamfile.v2 file with "<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and adding "<define>XML_STATIC".
I have another question: What exactly does <find-shared-library> do? Does it automatically define and use a lib target like:
lib xy : : <name>xy <link>shared ;
It's the other way around, actually. <find-shared-library> instructs to link against named library, so <find-shared-library>x results in -lx on linux (and x.lib on windows). 'shared' means to make sure it's actually shared. The 'xy' metatarget declaration you shown above essentially gets <find-shared-library>xy into build properties of every dependency. HTH, Volodya
On Tue, 28 Jul 2009 13:00:11 +0200, Vladimir Prus <vladimir@codesourcery.com> wrote:
[...]
I have another question: What exactly does <find-shared-library> do? Does it automatically define and use a lib target like:
lib xy : : <name>xy <link>shared ;
It's the other way around, actually. <find-shared-library> instructs to link against named library, so
<find-shared-library>x
results in
-lx
on linux (and x.lib on windows). 'shared' means to make sure it's actually shared.
If I need to set a path to x on a platform because I know <find-shared-library> won't be able to find x automatically can I add a "lib x" rule to a configuration file as a fallback mechanism? Then I could use <search> to help <find-shared-library> to find x? Boris
Boris Schaeling wrote:
On Tue, 28 Jul 2009 13:00:11 +0200, Vladimir Prus <vladimir@codesourcery.com> wrote:
[...]
I have another question: What exactly does <find-shared-library> do? Does it automatically define and use a lib target like:
lib xy : : <name>xy <link>shared ;
It's the other way around, actually. <find-shared-library> instructs to link against named library, so
<find-shared-library>x
results in
-lx
on linux (and x.lib on windows). 'shared' means to make sure it's actually shared.
If I need to set a path to x on a platform because I know <find-shared-library> won't be able to find x automatically can I add a "lib x" rule to a configuration file as a fallback mechanism? Then I could use <search> to help <find-shared-library> to find x?
You can, but it's somewhat non-direct. The <library-path> is the low-level feature. That is, if you define lib xy : : <name>xy <link>shared <search>foo ; the targets that use xy will get additional <find-shared-library>xy <library-path>foo properties. There are little reasons to directly use the latter features these days, to be honest. - Volodya
On Thu, 30 Jul 2009 11:57:12 +0200, Vladimir Prus <vladimir@codesourcery.com> wrote:
[...]You can, but it's somewhat non-direct. The <library-path> is the low-level feature. That is, if you define
lib xy : : <name>xy <link>shared <search>foo ;
the targets that use xy will get additional
<find-shared-library>xy <library-path>foo
properties. There are little reasons to directly use the latter features these days, to be honest.
Ah, so you recommend to always use the lib rule? Then I won't add <find-shared-library> and <library-path> to my tutorial - if there are too many details and too many options people just get lost and probably give up trying to find out what to use when. Boris
Boris Schaeling wrote:
On Thu, 30 Jul 2009 11:57:12 +0200, Vladimir Prus <vladimir@codesourcery.com> wrote:
[...]You can, but it's somewhat non-direct. The <library-path> is the low-level feature. That is, if you define
lib xy : : <name>xy <link>shared <search>foo ;
the targets that use xy will get additional
<find-shared-library>xy <library-path>foo
properties. There are little reasons to directly use the latter features these days, to be honest.
Ah, so you recommend to always use the lib rule? Then I won't add <find-shared-library> and <library-path> to my tutorial - if there are too many details and too many options people just get lost and probably give up trying to find out what to use when.
Yes, I think that right :-) *Users* should not have to use those features. - Volodya
KTC wrote:
Users on Microsoft Windows should be able to build boost with everything, both in terms of all supported variants and all boost libraries, with a single command to bjam assuming they have all the optional supporting libraries available.
An user download boost, and want to build all the libraries that require building go read the Getting Started Guide <.../getting_started/windows.html#invoke-bjam> and see the after getting bjam they use the command bjam --build-dir=build-directory toolset=toolset-name --build-type=complete stage
So they enter that into the command prompt and see lots of warnings and notes about missing optional components. The warnings and notes itself is fine and informative. Actually, it's incomplete as it stand as it doesn't tell the user about Boost.IOStreams optional component requirement of bzip2 & zlib headers. Okay, the user go and install all the optional components the warnings and notes tell them. After installing Python, ICU (building it first), Expat (building it first), and MPI (say MS-MPI), they try again. This time with the command becoming bjam --toolset=... --build-dir=... --build-type=complete -sHAVE_ICU=1 -sICU_PATH="..." -sEXPAT_INCLUDE="..." -sEXPAT_LIBPATH="..." -sBZIP2_SOURCE="..." -sZLIB_SOURCE="..." stage
Nope, MPI requires modification of user-config.jam or building it on its own with --with-mpi. Why? No other optional components build that way. So they look to see how they do that, and does it.
Do you actually want Boost.MPI? I kinda expect anybody who wants to use Boost.MPI to already have MPI installed.
Second attempt and ... nope. New to 1.39 is the errors error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use due to the changes made as a result of <http://lists.boost.org/Archives/boost/2009/04/150675.php>. (Recently noted on <http://groups.google.com/group/boost-list/browse_thread/thread/2a7bd07468b5ffe6>.) While catching those errors is good, maybe it should be fixed as well such that it doesn't come up in the first place if someone do a --build-type=complete with ICU. So now the users have to build Boost.Regex separately from the rest of the library (after finding how to pass the link= & runtime-link= options). By the way, at this point I would like to point out how it's strange that -sHAVE_ICU=1 mean to build with ICU, but so is -sHAVE_ICU=0 .... :S
And ... nope, even separately Boost.Regex still wouldn't build without errors. No one told them they need to rename icuin.lib, icuind.lib, icuind.pdb & icudt.lib from ICU to icui18n.lib, icui18nd.lib, icui18nd.pdb & icudata.lib respectively.
With Boost.Regex built, we turn to the rest of the library with --without-regex. After waiting a while, we discover ... nope, Most of the library is built but not Boost.Graph. Sorry, this time no one told them they need to change Boost.Graph's Jamfile.v2 file with "<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and adding "<define>XML_STATIC".
Boost is great, it's free, it's flexible and I understand it's developed for free by volunteers, but its "installation" for someone that want every libraries could be improved. :-)
Did you file any issues at svn.boost.org? This is the first time I hear about any expat-related problems whatsoever. This is also the first time I hear about "renaming" ICU libraries. As for the runtime-link incompatibility, my impression was that John did not see anything worth fixing there. - Volodya
On 28 Jul 2009, at 11:46, Vladimir Prus wrote:
KTC wrote:
Users on Microsoft Windows should be able to build boost with everything, both in terms of all supported variants and all boost libraries, with a single command to bjam assuming they have all the optional supporting libraries available.
An user download boost, and want to build all the libraries that require building go read the Getting Started Guide <.../getting_started/windows.html#invoke-bjam> and see the after getting bjam they use the command bjam --build-dir=build-directory toolset=toolset-name --build-type=complete stage
So they enter that into the command prompt and see lots of warnings and notes about missing optional components. The warnings and notes itself is fine and informative. Actually, it's incomplete as it stand as it doesn't tell the user about Boost.IOStreams optional component requirement of bzip2 & zlib headers. Okay, the user go and install all the optional components the warnings and notes tell them. After installing Python, ICU (building it first), Expat (building it first), and MPI (say MS-MPI), they try again. This time with the command becoming bjam --toolset=... --build-dir=... --build-type=complete - sHAVE_ICU=1 -sICU_PATH="..." -sEXPAT_INCLUDE="..." -sEXPAT_LIBPATH="..." -sBZIP2_SOURCE="..." -sZLIB_SOURCE="..." stage
Nope, MPI requires modification of user-config.jam or building it on its own with --with-mpi. Why? No other optional components build that way. So they look to see how they do that, and does it.
Do you actually want Boost.MPI? I kinda expect anybody who wants to use Boost.MPI to already have MPI installed.
Then, why not have boost try to detect MPI, and then build/install Boost.MPI in that case automatically? On Mac OS X, MPI is installed as a system library, yet I still have to document and describe the unusual procedure required to install boost.MPI to users. This single feature has left us close to dumping Boost.MPI in favour of another option. Chris
Hi ! On Tuesday 28 July 2009, Christopher Jefferson wrote:
On 28 Jul 2009, at 11:46, Vladimir Prus wrote:
Do you actually want Boost.MPI? I kinda expect anybody who wants to use Boost.MPI to already have MPI installed.
Then, why not have boost try to detect MPI, and then build/install Boost.MPI in that case automatically?
Well, as usual: Patches welcome. Creating a bulletproof autodetection system is not trivial. And requires manpower no one has provided yet. But the need is growing since Boost is getting more dependent on 3rdparty libs/tools like Expat/MPI.
On Mac OS X, MPI is installed as a system library, yet I still have to document and describe the unusual procedure required to install boost.MPI to users. This single feature has left us close to dumping Boost.MPI in favour of another option.
Well, I just quote Dave: "Just a bunch of sources". Just add them to your project/IDE/whatever and build the library yourself. Been there, done that for Boost.Test on Windows. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
On Tue, Jul 28, 2009 at 8:26 AM, Juergen Hunold<juergen.hunold@ivembh.de> wrote:
Hi !
On Tuesday 28 July 2009, Christopher Jefferson wrote:
On 28 Jul 2009, at 11:46, Vladimir Prus wrote:
Do you actually want Boost.MPI? I kinda expect anybody who wants to use Boost.MPI to already have MPI installed.
Then, why not have boost try to detect MPI, and then build/install Boost.MPI in that case automatically?
Well, as usual: Patches welcome. Creating a bulletproof autodetection system is not trivial. And requires manpower no one has provided yet. But the need is growing since Boost is getting more dependent on 3rdparty libs/tools like Expat/MPI.
I am curious, I know Expat is an XML parser or something like that, but if those libraries that use it do not use features like DTD verification and such, why not just make an XML parser in Spirit2.1, it is certainly proven to be just about faster then anything else yet tested. Also, I have never used an MPI system, but from quick perusing of what MPI based systems look like, why does Boost.MPI create a full MPI system instead of just create a glue on top of it? Especially since all the MPI system I see seem to cost a rather ridiculous amounts of money? I am probably missing something about the MPI standard though, but I do not see what from a quick reading that would warrant such costs I see.
On Tue, Jul 28, 2009 at 8:45 AM, OvermindDL1<overminddl1@gmail.com> wrote:
Also, I have never used an MPI system, but from quick perusing of what MPI based systems look like, why does Boost.MPI create a full MPI system instead of just create a glue on top of it? Especially since all the MPI system I see seem to cost a rather ridiculous amounts of money? I am probably missing something about the MPI standard though, but I do not see what from a quick reading that would warrant such costs I see.
why doesn't Boost.MPI create a full MPI*
On 28 Jul 2009, at 15:46, OvermindDL1 wrote:
On Tue, Jul 28, 2009 at 8:45 AM, OvermindDL1<overminddl1@gmail.com> wrote:
Also, I have never used an MPI system, but from quick perusing of what MPI based systems look like, why does Boost.MPI create a full MPI system instead of just create a glue on top of it? Especially since all the MPI system I see seem to cost a rather ridiculous amounts of money? I am probably missing something about the MPI standard though, but I do not see what from a quick reading that would warrant such costs I see.
why doesn't Boost.MPI create a full MPI*
openMPI ( http://www.open-mpi.org/ ) is free, packaged by default on Mac OS X, and a quick wc count is about 2M lines of source. Reimplementing that would be a lot of work, although it might be easy to do on top of asio. Chris
On Tue, Jul 28, 2009 at 8:54 AM, Christopher Jefferson<chris@bubblescope.net> wrote:
On 28 Jul 2009, at 15:46, OvermindDL1 wrote:
On Tue, Jul 28, 2009 at 8:45 AM, OvermindDL1<overminddl1@gmail.com> wrote:
Also, I have never used an MPI system, but from quick perusing of what MPI based systems look like, why does Boost.MPI create a full MPI system instead of just create a glue on top of it? Especially since all the MPI system I see seem to cost a rather ridiculous amounts of money? I am probably missing something about the MPI standard though, but I do not see what from a quick reading that would warrant such costs I see.
why doesn't Boost.MPI create a full MPI*
openMPI ( http://www.open-mpi.org/ ) is free, packaged by default on Mac OS X, and a quick wc count is about 2M lines of source. Reimplementing that would be a lot of work, although it might be easy to do on top of asio.
The main platform I have to work on is Windows, and I had seen that before but disregarded it since it had no Windows support. However, I just checked, it looks like Windows support was *just* added (version 1.3.3, the current version, 1.3.4 is in progress), fascinating. Still, a completely in-boost option would allow for all the template magic everyone here knows, thus it could become higher performant then any other MPI library out. Possible incentive anyway. :) What about expat though, why not use something built-in?
On Tue, Jul 28, 2009 at 8:31 AM, OvermindDL1<overminddl1@gmail.com> wrote:
The main platform I have to work on is Windows, and I had seen that before but disregarded it since it had no Windows support. However, I just checked, it looks like Windows support was *just* added (version 1.3.3, the current version, 1.3.4 is in progress), fascinating.
MPICH2 and Microsoft's MS-MPI also provide MPI for Windows.
Still, a completely in-boost option would allow for all the template magic everyone here knows, thus it could become higher performant then any other MPI library out. Possible incentive anyway. :)
A completely in-Boost option is unlikely to ever perform as well as any of the aforementioned MPI implementations. Each of these implementations has had many man-years of optimization to extract the best performance out of today's networking hardware. Even if we managed to provide comparable performance for some common platform (say, TCP on Windows), we're certainly not going to be able to compete with vendor-optimized implementations for more specialized, high-performance networking hardware. - Doug
On Tue, Jul 28, 2009 at 9:48 AM, Doug Gregor<doug.gregor@gmail.com> wrote:
On Tue, Jul 28, 2009 at 8:31 AM, OvermindDL1<overminddl1@gmail.com> wrote:
The main platform I have to work on is Windows, and I had seen that before but disregarded it since it had no Windows support. However, I just checked, it looks like Windows support was *just* added (version 1.3.3, the current version, 1.3.4 is in progress), fascinating.
MPICH2 and Microsoft's MS-MPI also provide MPI for Windows.
Still, a completely in-boost option would allow for all the template magic everyone here knows, thus it could become higher performant then any other MPI library out. Possible incentive anyway. :)
A completely in-Boost option is unlikely to ever perform as well as any of the aforementioned MPI implementations. Each of these implementations has had many man-years of optimization to extract the best performance out of today's networking hardware. Even if we managed to provide comparable performance for some common platform (say, TCP on Windows), we're certainly not going to be able to compete with vendor-optimized implementations for more specialized, high-performance networking hardware.
Good point, I had not read about that. That is part of the possibly unstated info I was expecting, thanks.
OvermindDL1 wrote:
On Tue, Jul 28, 2009 at 8:45 AM, OvermindDL1<overminddl1@gmail.com> wrote:
Also, I have never used an MPI system, but from quick perusing of what MPI based systems look like, why does Boost.MPI create a full MPI system instead of just create a glue on top of it? Especially since all the MPI system I see seem to cost a rather ridiculous amounts of money? I am probably missing something about the MPI standard though, but I do not see what from a quick reading that would warrant such costs I see.
why doesn't Boost.MPI create a full MPI*
Christopher's answer is the basic reason, but there are some other facets. First, the MPI specification is big. It is documented at the MPI Forum, and is being revised as we speak. You can read the MPI 2.1 specification documents on line, or buy the 608 page book. Meetings on 2.2 and 3.0 are currently ongoing. http://www.mpi-forum.org/docs/docs.html Second is that to be useful the implementations have to be carefully tuned and tested. Some of the comercial packages simplify this by being very platform dependent. A boost implementation would not want to do that, and so the implementation gets harder. However, MPI is used for ultra high performance codes, so even a few percent performance difference is reason for a user to choose something else. Boost doesn't have the testing resources to play in this game. Third, there are a few widely used and high quality open source packages already available. OpenMPI is the best known and most modern but others include LamMPI, LaMPI, MPICH and more.Many installations are locked in to certain systems because they have gone through the extensive process of installing, tuning and getting to know one implementation. You would have to supply a lot of value to get them to change. Boost.MPI is intentionally designed to be package agnostic. Whatever the installation chooses, Boost.MPI should work with it. Fourth, MPI includes Fortran and C APIs, as well as a C++ API that is different from what Boost.MPI provides. To make a useful version, these would have to be included. Now is a particularly bad time to start the C++ part of this work, however. News from the MPI Forum is that the members of the forum think Boost.MPI is a far better C++ interface than the one they provided. They have also noticed that Boost.MPI uses the C bindings under the hood and not the C++ bindings. This combination has them considering first depricating and then removing the C++ bindings from the MPI specification in favor of telling people to look to libraries like Boost.MPI. In all, I just don't think trying to implement the underlying MPI as part of boost is a great choice. Maybe you could do it and convince me I'm wrong, but I think there are better uses for your time. (Which might include contributing to one of the existing MPI packages.) John
Christopher Jefferson wrote:
On 28 Jul 2009, at 11:46, Vladimir Prus wrote:
KTC wrote:
Users on Microsoft Windows should be able to build boost with everything, both in terms of all supported variants and all boost libraries, with a single command to bjam assuming they have all the optional supporting libraries available.
An user download boost, and want to build all the libraries that require building go read the Getting Started Guide <.../getting_started/windows.html#invoke-bjam> and see the after getting bjam they use the command bjam --build-dir=build-directory toolset=toolset-name --build-type=complete stage
So they enter that into the command prompt and see lots of warnings and notes about missing optional components. The warnings and notes itself is fine and informative. Actually, it's incomplete as it stand as it doesn't tell the user about Boost.IOStreams optional component requirement of bzip2 & zlib headers. Okay, the user go and install all the optional components the warnings and notes tell them. After installing Python, ICU (building it first), Expat (building it first), and MPI (say MS-MPI), they try again. This time with the command becoming bjam --toolset=... --build-dir=... --build-type=complete - sHAVE_ICU=1 -sICU_PATH="..." -sEXPAT_INCLUDE="..." -sEXPAT_LIBPATH="..." -sBZIP2_SOURCE="..." -sZLIB_SOURCE="..." stage
Nope, MPI requires modification of user-config.jam or building it on its own with --with-mpi. Why? No other optional components build that way. So they look to see how they do that, and does it.
Do you actually want Boost.MPI? I kinda expect anybody who wants to use Boost.MPI to already have MPI installed.
Then, why not have boost try to detect MPI, and then build/install Boost.MPI in that case automatically?
On Mac OS X, MPI is installed as a system library, yet I still have to document and describe the unusual procedure required to install boost.MPI to users. This single feature has left us close to dumping Boost.MPI in favour of another option.
Just to clarify -- the procedure is putting one line in user-config.jam, most likely just: using mpi ; ? It's also documented at http://www.boost.org/doc/libs/1_39_0/doc/html/mpi/getting_started.html#mpi.c... If you are saying that the above does not work, can you file an issue? If you are saying that the above should be automated, can you file an issue as well? - Volodya
On 28 Jul 2009, at 16:33, Vladimir Prus wrote:
Christopher Jefferson wrote:
On 28 Jul 2009, at 11:46, Vladimir Prus wrote:
KTC wrote:
Users on Microsoft Windows should be able to build boost with everything, both in terms of all supported variants and all boost libraries, with a single command to bjam assuming they have all the optional supporting libraries available.
An user download boost, and want to build all the libraries that require building go read the Getting Started Guide <.../getting_started/windows.html#invoke-bjam> and see the after getting bjam they use the command bjam --build-dir=build-directory toolset=toolset-name --build-type=complete stage
So they enter that into the command prompt and see lots of warnings and notes about missing optional components. The warnings and notes itself is fine and informative. Actually, it's incomplete as it stand as it doesn't tell the user about Boost.IOStreams optional component requirement of bzip2 & zlib headers. Okay, the user go and install all the optional components the warnings and notes tell them. After installing Python, ICU (building it first), Expat (building it first), and MPI (say MS-MPI), they try again. This time with the command becoming bjam --toolset=... --build-dir=... --build-type=complete - sHAVE_ICU=1 -sICU_PATH="..." -sEXPAT_INCLUDE="..." -sEXPAT_LIBPATH="..." -sBZIP2_SOURCE="..." -sZLIB_SOURCE="..." stage
Nope, MPI requires modification of user-config.jam or building it on its own with --with-mpi. Why? No other optional components build that way. So they look to see how they do that, and does it.
Do you actually want Boost.MPI? I kinda expect anybody who wants to use Boost.MPI to already have MPI installed.
Then, why not have boost try to detect MPI, and then build/install Boost.MPI in that case automatically?
On Mac OS X, MPI is installed as a system library, yet I still have to document and describe the unusual procedure required to install boost.MPI to users. This single feature has left us close to dumping Boost.MPI in favour of another option.
Just to clarify -- the procedure is putting one line in user- config.jam, most likely just:
using mpi ;
? It's also documented at http://www.boost.org/doc/libs/1_39_0/doc/html/mpi/getting_started.html#mpi.c...
If you are saying that the above does not work, can you file an issue? If you are saying that the above should be automated, can you file an issue as well?
I'll file an issue. The problem I had is that most people don't have a user-config.jam, and most libraries don't require them. It seems strange to many people they have to keep a file around in their home directory for building boost. Chris
Christopher Jefferson wrote:
If you are saying that the above does not work, can you file an issue? If you are saying that the above should be automated, can you file an issue as well?
I'll file an issue.
The problem I had is that most people don't have a user-config.jam, and most libraries don't require them. It seems strange to many people they have to keep a file around in their home directory for building boost.
You can create a file named project-config.jam in Boost's source directory, too. I personally find that putting configuration details into a file is superior approach compared to zillion of options or environment variables. Say, if you build a project with automake with zillion of configure options, those options are put directly in Makefile, in your build dir, so if you remove your build tree, you have to re-figure those options next time you build. In fact, this is a flaw shared by CMake -- if you configure some project as: cmake -Dfoo=blah -DBOOST_ROOT=whatever ../src it helpfully puts those options into the cache file. Unfortunately, when the configure magic confuses itself (which does happen), your only solution is to remove the cache, and then you need to recall and pass the same options again. - Volodya
On Wed, Jul 29, 2009 at 5:14 AM, Vladimir Prus<vladimir@codesourcery.com> wrote:
I personally find that putting configuration details into a file is superior approach compared to zillion of options or environment variables. Say, if you build a project with automake with zillion of configure options, those options are put directly in Makefile, in your build dir, so if you remove your build tree, you have to re-figure those options next time you build.
In fact, this is a flaw shared by CMake -- if you configure some project as:
cmake -Dfoo=blah -DBOOST_ROOT=whatever ../src
it helpfully puts those options into the cache file. Unfortunately, when the configure magic confuses itself (which does happen), your only solution is to remove the cache, and then you need to recall and pass the same options again.
FWIW, CMake has an option to provide an initial cache file (using -C cache-filename). So, you can place those configuration details into your own initial cache file, and ask CMake to start with that configuration (configuring whatever else it needs) if you need to re-configure your tree. - Doug
Doug Gregor wrote:
On Wed, Jul 29, 2009 at 5:14 AM, Vladimir Prus<vladimir@codesourcery.com> wrote:
I personally find that putting configuration details into a file is superior approach compared to zillion of options or environment variables. Say, if you build a project with automake with zillion of configure options, those options are put directly in Makefile, in your build dir, so if you remove your build tree, you have to re-figure those options next time you build.
In fact, this is a flaw shared by CMake -- if you configure some project as:
cmake -Dfoo=blah -DBOOST_ROOT=whatever ../src
it helpfully puts those options into the cache file. Unfortunately, when the configure magic confuses itself (which does happen), your only solution is to remove the cache, and then you need to recall and pass the same options again.
FWIW, CMake has an option to provide an initial cache file (using -C cache-filename). So, you can place those configuration details into your own initial cache file, and ask CMake to start with that configuration (configuring whatever else it needs) if you need to re-configure your tree.
Does initial cache use the same syntax as the ordinary cache, and can be edited using the GUI? - Volodya
On Wed, Jul 29, 2009 at 10:00 AM, Vladimir Prus<vladimir@codesourcery.com> wrote:
Doug Gregor wrote:
On Wed, Jul 29, 2009 at 5:14 AM, Vladimir Prus<vladimir@codesourcery.com> wrote:
I personally find that putting configuration details into a file is superior approach compared to zillion of options or environment variables. Say, if you build a project with automake with zillion of configure options, those options are put directly in Makefile, in your build dir, so if you remove your build tree, you have to re-figure those options next time you build.
In fact, this is a flaw shared by CMake -- if you configure some project as:
cmake -Dfoo=blah -DBOOST_ROOT=whatever ../src
it helpfully puts those options into the cache file. Unfortunately, when the configure magic confuses itself (which does happen), your only solution is to remove the cache, and then you need to recall and pass the same options again.
FWIW, CMake has an option to provide an initial cache file (using -C cache-filename). So, you can place those configuration details into your own initial cache file, and ask CMake to start with that configuration (configuring whatever else it needs) if you need to re-configure your tree.
Does initial cache use the same syntax as the ordinary cache,
Yes.
and can be edited using the GUI?
No, but that would be a big improvement. - Doug
Doug Gregor wrote:
On Wed, Jul 29, 2009 at 10:00 AM, Vladimir Prus<vladimir@codesourcery.com> wrote:
Doug Gregor wrote:
On Wed, Jul 29, 2009 at 5:14 AM, Vladimir Prus<vladimir@codesourcery.com> wrote:
I personally find that putting configuration details into a file is superior approach compared to zillion of options or environment variables. Say, if you build a project with automake with zillion of configure options, those options are put directly in Makefile, in your build dir, so if you remove your build tree, you have to re-figure those options next time you build.
In fact, this is a flaw shared by CMake -- if you configure some project as:
cmake -Dfoo=blah -DBOOST_ROOT=whatever ../src
it helpfully puts those options into the cache file. Unfortunately, when the configure magic confuses itself (which does happen), your only solution is to remove the cache, and then you need to recall and pass the same options again.
FWIW, CMake has an option to provide an initial cache file (using -C cache-filename). So, you can place those configuration details into your own initial cache file, and ask CMake to start with that configuration (configuring whatever else it needs) if you need to re-configure your tree.
Does initial cache use the same syntax as the ordinary cache,
Yes.
Hmm, does not work for me: $ cp CMakeCache.txt initial $ cmake -C initial . loading initial cache file initial CMake Error: Error in cmake code at /tmp/x/initial:17: Parse error. Expected a command name, got unquoted argument with text "//Path". CMake Error: Error processing file:initial -- Configuring incomplete, errors occurred! $ cmake --version cmake version 2.6-patch 2 Am I doing something wrong?
and can be edited using the GUI?
No, but that would be a big improvement.
OK. Regardless of the reason for the above error -- which might well be my error -- I think I now understand the attractive parts of CMake configuration framework, and will make use of that understanding. Thanks, Volodya
FWIW, CMake has an option to provide an initial cache file (using -C cache-filename). So, you can place those configuration details into your own initial cache file, and ask CMake to start with that configuration (configuring whatever else it needs) if you need to re-configure your tree.
Does initial cache use the same syntax as the ordinary cache,
Yes.
Hmm, does not work for me:
$ cp CMakeCache.txt initial $ cmake -C initial . loading initial cache file initial CMake Error: Error in cmake code at /tmp/x/initial:17: Parse error. Expected a command name, got unquoted argument with text "//Path". CMake Error: Error processing file:initial -- Configuring incomplete, errors occurred! $ cmake --version cmake version 2.6-patch 2
Am I doing something wrong?
The cmake file(s) that can be passed in via the "-C" option do not have the same syntax as CMakeCache.txt. Instead they have the normal CMake syntax (which I find easier to work with). For instance, you could have a file initial.cmake: # Contents of initial.cmake set(CMAKE_INSTALL_PREFIX "my/path/for/install" CACHE STRING "Where to put installed files" FORCE) This file could then be used: cmake -C initial.cmake my/path/to/source/tree
OK. Regardless of the reason for the above error -- which might well be my error -- I think I now understand the attractive parts of CMake configuration framework, and will make use of that understanding.
I would like to add that although the GUI and the easy to modify configuration of CMake is very nice, it is a very small fraction of the CMake configuration framework. Perhaps the more important feature is the ability to find third- party libraries on any number of host system configurations "automagically". I would expect that this feature is also one of the more difficult to duplicate. Respectfully, Justin
On Wed, Jul 29, 2009 at 11:21 AM, Doug Gregor<doug.gregor@gmail.com> wrote:
On Wed, Jul 29, 2009 at 10:00 AM, Vladimir Prus<vladimir@codesourcery.com> wrote:
Doug Gregor wrote:
FWIW, CMake has an option to provide an initial cache file (using -C cache-filename). So, you can place those configuration details into your own initial cache file, and ask CMake to start with that configuration (configuring whatever else it needs) if you need to re-configure your tree.
Does initial cache use the same syntax as the ordinary cache,
Yes.
Err, I was wrong; thanks to Justin for correcting my moronicity. - Doug
Vladimir Prus wrote:
KTC wrote:
Nope, MPI requires modification of user-config.jam or building it on its own with --with-mpi. Why? No other optional components build that way. So they look to see how they do that, and does it.
Do you actually want Boost.MPI? I kinda expect anybody who wants to use Boost.MPI to already have MPI installed.
Personally, probably not. But my issue with it was that MPI's build behaviour differ from all the other libraries. It's a minor thing anyway because it's well documented both in the docs, and in the text return from the build screen when building without specifying --without-mpi.
Did you file any issues at svn.boost.org? This is the first time I hear about any expat-related problems whatsoever.
Not yet. Trac kinda confuses me. :D I never encountered the expat issue before either because I've only just upgraded to 1.39, and it's the first time I tried building with expat. I'll file something though. KTC -- Only two things are infinite, the Universe and Stupidity. And I'm not quite sure about the former. - Albert Einstein
KTC wrote:
Users on Microsoft Windows should be able to build boost with everything, both in terms of all supported variants and all boost libraries, with a single command to bjam assuming they have all the optional supporting libraries available.
An user download boost, and want to build all the libraries that require building go read the Getting Started Guide <.../getting_started/windows.html#invoke-bjam> and see the after getting bjam they use the command bjam --build-dir=build-directory toolset=toolset-name --build-type=complete stage
So they enter that into the command prompt and see lots of warnings and notes about missing optional components. The warnings and notes itself is fine and informative. Actually, it's incomplete as it stand as it doesn't tell the user about Boost.IOStreams optional component requirement of bzip2 & zlib headers. Okay, the user go and install all the optional components the warnings and notes tell them. After installing Python, ICU (building it first), Expat (building it first), and MPI (say MS-MPI), they try again. This time with the command becoming bjam --toolset=... --build-dir=... --build-type=complete -sHAVE_ICU=1 -sICU_PATH="..." -sEXPAT_INCLUDE="..." -sEXPAT_LIBPATH="..." -sBZIP2_SOURCE="..." -sZLIB_SOURCE="..." stage
Nope, MPI requires modification of user-config.jam or building it on its own with --with-mpi. Why? No other optional components build that way. So they look to see how they do that, and does it.
Second attempt and ... nope. New to 1.39 is the errors error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use due to the changes made as a result of <http://lists.boost.org/Archives/boost/2009/04/150675.php>. (Recently noted on <http://groups.google.com/group/boost-list/browse_thread/thread/2a7bd07468b5ffe6>.) While catching those errors is good, maybe it should be fixed as well such that it doesn't come up in the first place if someone do a --build-type=complete with ICU. So now the users have to build Boost.Regex separately from the rest of the library (after finding how to pass the link= & runtime-link= options). By the way, at this point I would like to point out how it's strange that -sHAVE_ICU=1 mean to build with ICU, but so is -sHAVE_ICU=0 .... :S
And ... nope, even separately Boost.Regex still wouldn't build without errors. No one told them they need to rename icuin.lib, icuind.lib, icuind.pdb & icudt.lib from ICU to icui18n.lib, icui18nd.lib, icui18nd.pdb & icudata.lib respectively.
With Boost.Regex built, we turn to the rest of the library with --without-regex. After waiting a while, we discover ... nope, Most of the library is built but not Boost.Graph. Sorry, this time no one told them they need to change Boost.Graph's Jamfile.v2 file with "<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and adding "<define>XML_STATIC".
Boost is great, it's free, it's flexible and I understand it's developed for free by volunteers, but its "installation" for someone that want every libraries could be improved. :-)
Regards,
KTC
I'm just looking forward to the day when the current CMake support exposes all of this optional functionality (variants, zlib, bzip2, etc.) as CMake variables that I can happily configure via the CMake gui, push a button, and build exactly what I want. For some reason, CMake seems much more intuitive to me, both in syntax and structure, than using bjam.
Kenny Riddile wrote:
Boost is great, it's free, it's flexible and I understand it's developed for free by volunteers, but its "installation" for someone that want every libraries could be improved. :-)
Regards,
KTC
I'm just looking forward to the day when the current CMake support exposes all of this optional functionality (variants, zlib, bzip2, etc.) as CMake variables that I can happily configure via the CMake gui,
Are you suggesting that a UI where you see all configuration variables immediately, and can tweak them, is a good idea? - Volodya
Vladimir Prus wrote:
Kenny Riddile wrote:
Boost is great, it's free, it's flexible and I understand it's developed for free by volunteers, but its "installation" for someone that want every libraries could be improved. :-)
Regards,
KTC
I'm just looking forward to the day when the current CMake support exposes all of this optional functionality (variants, zlib, bzip2, etc.) as CMake variables that I can happily configure via the CMake gui,
Are you suggesting that a UI where you see all configuration variables immediately, and can tweak them, is a good idea?
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Do I sense some sarcasm? :)
Kenny Riddile wrote:
Are you suggesting that a UI where you see all configuration variables immediately, and can tweak them, is a good idea?
Do I sense some sarcasm? :)
There was none intended -- I actually wanted to know the answer to that question. In part, because you specifically mentioned the gui as good thing, so I want to find out *what* is attractive exactly. There's of course hidden agenda somewhere there, but it does not affect genuinity of the question. - Volodya
Vladimir Prus wrote:
Kenny Riddile wrote:
Are you suggesting that a UI where you see all configuration variables immediately, and can tweak them, is a good idea?
Do I sense some sarcasm? :)
There was none intended -- I actually wanted to know the answer to that question. In part, because you specifically mentioned the gui as good thing, so I want to find out *what* is attractive exactly.
There's of course hidden agenda somewhere there, but it does not affect genuinity of the question.
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Oh, then yes, I am unequivocally saying that is a good thing, especially when the GUI runs on all major platforms and has fairly intuitive command-line alternatives to fall back on. Just as in programming, having a good interface prevents confusion and misuse. A GUI has the ability to make it immediately clear which variables are available and which values are valid for each variable. Doing that without a GUI usually requires reading through separate textual documentation and piecing together the information you need.
Kenny Riddile wrote:
Vladimir Prus wrote:
Kenny Riddile wrote:
Are you suggesting that a UI where you see all configuration variables immediately, and can tweak them, is a good idea?
Do I sense some sarcasm? :)
There was none intended -- I actually wanted to know the answer to that question. In part, because you specifically mentioned the gui as good thing, so I want to find out *what* is attractive exactly.
There's of course hidden agenda somewhere there, but it does not affect genuinity of the question.
Oh, then yes, I am unequivocally saying that is a good thing, especially when the GUI runs on all major platforms and has fairly intuitive command-line alternatives to fall back on. Just as in programming, having a good interface prevents confusion and misuse. A GUI has the ability to make it immediately clear which variables are available and which values are valid for each variable. Doing that without a GUI usually requires reading through separate textual documentation and piecing together the information you need.
Noted, thanks! - Volodya
Kenny Riddile wrote:
I'm just looking forward to the day when the current CMake support exposes all of this optional functionality (variants, zlib, bzip2, etc.) as CMake variables that I can happily configure via the CMake gui, push a button, and build exactly what I want.
AFAIK it does already. You could join the boost-cmake list: http://lists.boost.org/mailman/listinfo.cgi/boost-cmake -t
troy d. straszheim wrote:
Kenny Riddile wrote:
I'm just looking forward to the day when the current CMake support exposes all of this optional functionality (variants, zlib, bzip2, etc.) as CMake variables that I can happily configure via the CMake gui, push a button, and build exactly what I want.
AFAIK it does already. You could join the boost-cmake list:
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
-t
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
After some digging in the current CMake scripts, I see that in the case of IOStreams, it searches in certain standard locations for both zlib and bzip2 and automatically adds support for them if they are found. This isn't quite what I was talking about above, but I guess that's a discussion for the CMake list.
participants (15)
-
Boris Schaeling -
Christopher Jefferson -
Dmitry Goncharov -
Doug Gregor -
Gennadiy Rozental -
John Maddock -
John Phillips -
Juergen Hunold -
Kenny Riddile -
KSpam -
KTC -
OvermindDL1 -
Steven Watanabe -
troy d. straszheim -
Vladimir Prus