Newbee: Build/Installation Questions
Hi there, I'm still uncertain how to properly build and install boost libraries under Solaris 7. I unpacked the boost_1_30_0.tar.gz file and ran from the boost_1_30_0/libs/test/build directory: $ jam -sTOOLS=sunpro -sBUILD="debug release" \ -sALL_LOCATE_TARGET=/opt/boost_1.30.0 This created some of the lib files below /opt/boost_1.30.0/libs/test/build/bin/... Not all of them because in release mode compiling the file boost_1_30_0/libs/test/src/unit_test_log.cpp failed several times: [...] sunpro-C++-action /opt/boost_1.30.0/libs/test/build/bin/libboost_test_exec_monitor.a/sunpro/release/runtime-link-dynamic/unit_test_log.o Assertion failure in prep_dot
Assertion: (../links/prepexpression.cc, line 560) while processing ../src/unit_test_log.cpp at line 301.
CC -c -DNDEBUG -fast -O4 -xtarget=generic -features=rtti -features=except -I"/opt/boost_1.30.0/libs/test/build" -I"/home/hwadm/Boost/boost_1_30_0" -o "/opt/boost_1.30.0/libs/test/build/bin/libboost_test_exec_monitor.a/sunpro/release/runtime-link-dynamic/unit_test_log.o" "../src/unit_test_log.cpp" ...failed sunpro-C++-action /opt/boost_1.30.0/libs/test/build/bin/libboost_test_exec_monitor.a/sunpro/release/runtime-link-dynamic/unit_test_log.o... [...] Line 301 and around in this file look so: //____________________________________________________________________________// unit_test_log& unit_test_log::operator<<( checkpoint const& cp ) { if( m_pimpl->m_entry_in_progress ) m_pimpl->set_checkpoint( cp ); // LINE 301 return *this; } //____________________________________________________________________________// I cannot see any complexity here that could lead to an assertion. As I learned from the Boost Users Mailinglist archive such assertions seem to be common problems with Sun's forte 6.2 and 7 compilers. O.k. When the build above was finished I got at least the libs. built in debug mode obvisously completely installed below /opt/boost_1.30.0/libs/test/build/bin/<libs>/sunpro/... To get the header files installed I ran $ bjam -sTOOLS=sunpro -sBUILD=install But this command did not install the header files which would be required to use the test library. Instead a complex directory structure was created below ../sunpro/install. Is there no way to automatically get all the header files that belong to the test lib plus the other boost header files used by this lib installed automatically? Many thanks in advance for any hint. Regards, Adalbert Perbandt.
Adalbert Perbandt <adalbert.perbandt@infineon.com> writes:
To get the header files installed I ran
$ bjam -sTOOLS=sunpro -sBUILD=install
Nope. "install" is not a build variant.
But this command did not install the header files which would be required to use the test library. Instead a complex directory structure was created below ../sunpro/install.
Is there no way to automatically get all the header files that belong to the test lib plus the other boost header files used by this lib installed automatically?
Nope. Being able to isolate header dependencies and separate them from the rest of Boost is not a feature we have implemented. Boost is meant to be installed "en masse" -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David" == David Abrahams <dave@boost-consulting.com> writes:
David> Adalbert Perbandt <adalbert.perbandt@infineon.com> writes: >> To get the header files installed I ran >> >> $ bjam -sTOOLS=sunpro -sBUILD=install David> Nope. "install" is not a build variant. Hmm, seems to me if I misunderstood something. I found a set of so called "Pseudotargets: described in the tools/build/jam_src/Jambase.html page. In between I followed your hint in a reply to another question and specified the installation directory like this: $ bjam -sTOOLS=sunpro -sALL_LOCATE_TARGET=<installDir> [...] David> Nope. Being able to isolate header dependencies and David> separate them from the rest of Boost is not a feature we David> have implemented. Boost is meant to be installed "en David> masse" O.k. So I simply copy the whole directory tree including and below the "boost" directory into my installation dir and configure the compiler with -I<install_path>. I wonder why the installation directory-hierarchy is that complex. Each one of the libs. is stored under a seprate directory: <installDir>/ libs/ test/ build/ bin/ <libName>/ sunpro/ debug|release/ runtime-link-dynamic/ <libFile> If I want to use more than one lib I have to specify multiple lengthy -L options for the link command pointing to each of the required libraries's directories. What is the rational behind this directory structure? I would find it more convenient if I had all the libs that were build the same way (same compiler, same compile mode [debug/release] stored together in one directory. What does this directory "runtime-link-dynamic/" mean? Sorry if these are stupid questions. I'm not that experienced yet with using C++ libraries (except the STL) in my projects. Thanks in advance for any hint. Regards, Adalbert Perbandt.
Adalbert Perbandt <adalbert.perbandt@infineon.com> writes:
"David" == David Abrahams <dave@boost-consulting.com> writes:
David> Adalbert Perbandt <adalbert.perbandt@infineon.com> writes: >> To get the header files installed I ran >> >> $ bjam -sTOOLS=sunpro -sBUILD=install
David> Nope. "install" is not a build variant.
Hmm, seems to me if I misunderstood something. I found a set of so called "Pseudotargets: described in the tools/build/jam_src/Jambase.html page.
We should probably get rid of that; it only applies to "Classic Jam", not Boost.Build. But anyway, pseudotargets are not the same as build variants.
In between I followed your hint in a reply to another question and specified the installation directory like this:
$ bjam -sTOOLS=sunpro -sALL_LOCATE_TARGET=<installDir>
[...] David> Nope. Being able to isolate header dependencies and David> separate them from the rest of Boost is not a feature we David> have implemented. Boost is meant to be installed "en David> masse"
O.k. So I simply copy the whole directory tree including and below the "boost" directory into my installation dir and configure the compiler with -I<install_path>.
Yep.
I wonder why the installation directory-hierarchy is that complex. Each one of the libs. is stored under a seprate directory:
<installDir>/ libs/ test/ build/ bin/ <libName>/ sunpro/ debug|release/ runtime-link-dynamic/ <libFile>
That's not the installation directory hierarchy, it's the build directory hierarchy. We don't have a formal intallation process; the closest we have are stage targets which typically get built into less-deep directories. The reason for the long paths is to isolate different link-incompatible variants that you might build of a library. The Boost.Build system is doing that for developers more than for installers. The user-expected-installation-behavior problem is one we have yet to solve well.
If I want to use more than one lib I have to specify multiple lengthy -L options for the link command pointing to each of the required libraries's directories.
Just copy the library to a less-onerous place then.
What is the rational behind this directory structure?
See above.
I would find it more convenient if I had all the libs that were build the same way (same compiler, same compile mode [debug/release] stored together in one directory.
I'm sure. We'd appreciate your participation in the Boost.Build v2 project. See http://www.boost.org/more/mailing_lists.htm to get on the mailing list.
What does this directory "runtime-link-dynamic/" mean?
It means that the library is built to link with the shared runtime as opposed to the static one.
Sorry if these are stupid questions. I'm not that experienced yet with using C++ libraries (except the STL) in my projects.
No problem; they're not stupid. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David" == David Abrahams <dave@boost-consulting.com> writes:
>> Hmm, seems to me if I misunderstood something. I found a set >> of so called "Pseudotargets: described in the >> tools/build/jam_src/Jambase.html page. David> We should probably get rid of that; it only applies to David> "Classic Jam", not Boost.Build. But anyway, pseudotargets David> are not the same as build variants. O.k. As far as I understand build variants are configured using the BUILD environment variable (or the -sBUILD=...) option, correct? Until now I know of the variants "debug" and "release". And obviously one can specify some modifiers like "<optimization>speed" or "<runtime-link>static|dynamic>", "<debug-symbols>on" and maybe more. I think it should be very simple to find out which build variants and modifiers are defined because this information must be stored in some of the Jam config files. Correct? Just searched through the boost_1_30_0 directories and found such info in the Toolset jam files, e. g. tools/build/sunpro-tools.jam. Somehow a default set of these modifiers must exist for the case that the user did not specify anyone(?) >> In between I followed your hint in a reply to another question >> and specified the installation directory like this: >> >> $ bjam -sTOOLS=sunpro -sALL_LOCATE_TARGET=<installDir> >> >> [...] David> Nope. Being able to isolate header dependencies and David> separate them from the rest of Boost is not a feature we David> have implemented. Boost is meant to be installed "en David> masse" O.k. I think, this is an acceptable solution because all the Boost libs might be very useful -- if I only could get them all compiled with Sun's Forte compiler:-((( But this problem should be solved somewhen in the future. [...] David> I'm sure. We'd appreciate your participation in the David> Boost.Build v2 project. See David> http://www.boost.org/more/mailing_lists.htm to get on the David> mailing list. Thanks, just subscribed to the jamboost Boost Build mailing list. I'm still very new to the build tool BJam. So first I have to learn more about its functioning before being able to contribute. Regards, Adalbert Perbandt.
Moving this thread to Jamboost... Adalbert Perbandt <adalbert.perbandt@infineon.com> writes:
"David" == David Abrahams <dave@boost-consulting.com> writes:
>> Hmm, seems to me if I misunderstood something. I found a set >> of so called "Pseudotargets: described in the >> tools/build/jam_src/Jambase.html page.
David> We should probably get rid of that; it only applies to David> "Classic Jam", not Boost.Build. But anyway, pseudotargets David> are not the same as build variants.
O.k. As far as I understand build variants are configured using the BUILD environment variable (or the -sBUILD=...) option, correct?
Right.
Until now I know of the variants "debug" and "release". And obviously one can specify some modifiers like "<optimization>speed" or "<runtime-link>static|dynamic>", "<debug-symbols>on" and maybe more. I think it should be very simple to find out which build variants and modifiers are defined because this information must be stored in some of the Jam config files. Correct?
see tools/build/features.jam
Just searched through the boost_1_30_0 directories and found such info in the Toolset jam files, e. g. tools/build/sunpro-tools.jam. Somehow a default set of these modifiers must exist for the case that the user did not specify anyone(?)
The variant specifies the first layer of defaults. Anything not in the variant is taken from the feature's first value. Finally, target requirements may override those values.
>> In between I followed your hint in a reply to another question >> and specified the installation directory like this: >> >> $ bjam -sTOOLS=sunpro -sALL_LOCATE_TARGET=<installDir> >> >> [...] David> Nope. Being able to isolate header dependencies and David> separate them from the rest of Boost is not a feature we David> have implemented. Boost is meant to be installed "en David> masse"
O.k. I think, this is an acceptable solution because all the Boost libs might be very useful -- if I only could get them all compiled with Sun's Forte compiler:-(((
Sun has a lot of bugs to fix before that can happen.
[...] David> I'm sure. We'd appreciate your participation in the David> Boost.Build v2 project. See David> http://www.boost.org/more/mailing_lists.htm to get on the David> mailing list.
Thanks, just subscribed to the jamboost Boost Build mailing list. I'm still very new to the build tool BJam. So first I have to learn more about its functioning before being able to contribute.
Regards,
Adalbert Perbandt.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
Adalbert Perbandt -
David Abrahams