|
|
Boost-Build : |
From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-09-24 19:14:09
On 9/23/05, David Abrahams <dave_at_[hidden]> wrote:
>
> Caleb Epstein <caleb.epstein_at_[hidden]> writes:
>
> > On 9/22/05, David Abrahams <dave_at_[hidden]> wrote:
> >>
> >> > I should mention that c:\boost is an installed copy of boost, not a
> >> > full source tree. That is, I downloaded the source and ran 'bjam
> >> > install'. So it has an include directory and a lib directory but no
> >> > sources other than the headers in include.
> >>
> >> Oh, well, that's dumb. We should fix that.
> >
> >
> > This is one of the major mind-bogglers I have encountered when
> > trying to use Boost Build. You can't use it with an installed Boost
> > directory, only with the unpacked source distribution.
>
> No, that's certainly not true. You can use its library files directly
> and add its include directory to the #include path. Or, in your
OK, my "can't" is too strong a word here. But all of the
Boost.Buildexamples walk the user through examples which only work if
the BOOST_ROOT
you're using is the unpacked source tree. I think they should be made work
in both the unpacked source tree and installed include/lib tree cases. In
fact, Boost.Build itself isn't installed with "bjam install".
Jamfile, you can create prebuilt targets corresponding to the
> libraries, and you can even add usage requirements to these targets
> that, e.g., relieve the need to explicitly specify #include paths.
> However, those target definitions should in fact be present in a
> Jamfile created by the install process. That basic idea was first
> proposed by Ullrich Koethe long ago
> (
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Configuration_And_Installation
> ).
This is within spitting distance of what I'm thinking about. I like "3rd
party" software dependencies (e.g. code that I didn't write and that I don't
generally maintain) to appear in binary form. I build them from source and
install them in some well-known location (like Ullrich's /software
hierarchy) and then compile and link my applications by pointing only to
this installation directory. Never does anything reference the unpacked
source directory, which often ends up simply being removed.
We are currently using Boost this way with our own home-grown set of build
tools based on GNU make, but I'm trying to dip a toe in the Boost Build
waters and ran into the "it's not installed" problem pretty quickly :)
> That doesn't seem like the best idea to me, especially since the
> > layout of the bin[.v2] directory doesn't take into account
> > architecture-specifics (e.g. I have
> > $BOOST_ROOT/bin.v2/libs/test/build/gcc; are those from gcc-on-Linux
> > or gcc-on-Solaris?)
>
> Hmm, that's a different problem. I do agree we should address it.
Just one more level, or one more-detailed directory name would solve it. For
example, as testers we are encouraged to use toolset names like
"<compiler>-<version>-<platform>". What if Boost.Build used this type of
name insetad of the too-vague e.g. "gcc" directory name it currently uses?
This could be an optional behavior for those folks like me (and I assume
others, perhaps even yourself) who build from the same source tree for
multiple architectures, possibly using the same compiler. I guess its
do-able today by provding a custom toolset definition, but it would be nice
to be able to enable it with a simple switch (e.g. perhaps
"<layout>arch-specific") instead.
> > What I would expect would be that "bjam install" would install all of
> the
> > Boost headers, compiled libraries, the Boost Build plumbing,
>
> What plumbing did you have in mind?
The contents of $BOOST_ROOT/tools/build/v1 and v2. These are not currently
installed via "bjam install". So you can't use Boost.Build without an
unpacked copy of the Boost sources (or some subset thereof). The
pre-packaged versions of Boost that are available for various flavors of
Linux and other platforms don't end up including Boost.Build for this
reason.
If Boost Build is a tool like Boost Regex and Boost Python etc, it should be
installed too!
> > and any Jamfiles[.v2] necessary to link with those compiled
> > libraries. These Jamfiles might necessarily be different than the
> > ones used to build the library in the first place. They should only
> > provide information about the required compiler flags for building
> > code that links with the library, and the necessary library names to
> > link. There should be no information about how to build the library
> > itself, since the sources aren't available.
>
> It sounds like you're describing Ullrich's idea. Care to implement
> it?
I find myself generally stymied by bjam/Boost.Build syntax and constructs,
so I don't feel like I'm up to the job currently. The documentation for BBv2
is unfortunately not complete enough for me to learn what I need to know
without help. I understand it (BBv2) is a work in progress, so an
up-to-minute reference is hard to provide, but I think I need more than what
is currently available to be able to implement this correctly. I'd gladly
accept help from someone who knows more than me, to get me up to speed. Once
I'm more comfortable with the tool I can probably make it happen.
I'm sorry I wont be attending the SD Expo this coming week. So many meaty
sessions I wanted to attend, but once again our budget has dried up.
-- Caleb Epstein caleb dot epstein at gmail dot com ------=_Part_15700_17866455.1127607249036 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 9/23/05, <b class="gmail_sendername">David Abrahams</b> <<a href="mailto:dave_at_[hidden]">dave_at_[hidden]</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Caleb Epstein <<a href="mailto:caleb.epstein_at_[hidden]">caleb.epstein_at_[hidden]</a>> writes:<br><br>> On 9/22/05, David Abrahams <<a href="mailto:dave_at_[hidden]">dave_at_[hidden]</a>> wrote: <br>>><br>>> > I should mention that c:\boost is an installed copy of boost, not a<br>>> > full source tree. That is, I downloaded the source and ran 'bjam<br>>> > install'. So it has an include directory and a lib directory but no <br>>> > sources other than the headers in include.<br>>><br>>> Oh, well, that's dumb. We should fix that.<br>><br>><br>> This is one of the major mind-bogglers I have encountered when<br>> trying to use Boost Build. You can't use it with an installed Boost <br>> directory, only with the unpacked source distribution.<br><br>No, that's certainly not true. You can use its library files directly<br>and add its include directory to the #include path. Or, in your</blockquote> <div><br> OK, my "can't" is too strong a word here. But all of the Boost.Build examples walk the user through examples which only work if the BOOST_ROOT you're using is the unpacked source tree. I think they should be made work in both the unpacked source tree <span style="font-weight: bold;">and</span> installed include/lib tree cases. In fact, Boost.Build itself isn't installed with "bjam install".<br> </div><br><blockquote class="gmail_quote" style="border-left: 1pxsolid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Jamfile, you can create prebuilt targets corresponding to the<br>libraries, and you can even add usage requirements to these targets <br>that, e.g., relieve the need to explicitly specify #include paths.<br>However, those target definitions should in fact be present in a<br>Jamfile created by the install process. That basic idea was first<br>proposed by Ullrich Koethe long ago <br>(http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Configuration_And_Installation).</blockquote> <div><br> <br> This is within spitting distance of what I'm thinking about. I like "3rd party" software dependencies (e.g. code that I didn't write and that I don't generally maintain) to appear in binary form. I build them from source and install them in some well-known location (like Ullrich's /software hierarchy) and then compile and link my applications by pointing only to this installation directory. Never does anything reference the unpacked source directory, which often ends up simply being removed.<br> <br> We are currently using Boost this way with our own home-grown set of build tools based on GNU make, but I'm trying to dip a toe in the Boost Build waters and ran into the "it's not installed" problem pretty quickly :)<br> <br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solidrgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> That doesn't seem like the best idea to me, especially since the<br>> layout of the bin[.v2] directory doesn't take into account <br>> architecture-specifics (e.g. I have<br>> $BOOST_ROOT/bin.v2/libs/test/build/gcc; are those from gcc-on-Linux<br>> or gcc-on-Solaris?)<br><br>Hmm, that's a different problem. I do agree we should address it. </blockquote><div><br> Just one more level, or one more-detailed directory name would solve it. For example, as testers we are encouraged to use toolset names like "<compiler>-<version>-<platform>". What if Boost.Build used this type of name insetad of the too-vague e.g. "gcc" directory name it currently uses? This could be an optional behavior for those folks like me (and I assume others, perhaps even yourself) who build from the same source tree for multiple architectures, possibly using the same compiler. I guess its do-able today by provding a custom toolset definition, but it would be nice to be able to enable it with a simple switch (e.g. perhaps "<layout>arch-specific") instead.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> What I would expect would be that "bjam install" would install all of the <br>> Boost headers, compiled libraries, the Boost Build plumbing,<br><br>What plumbing did you have in mind?</blockquote><div><br> The contents of $BOOST_ROOT/tools/build/v1 and v2. These are <span style="font-weight: bold;">not</span> currently installed via "bjam install". So you can't use Boost.Build without an unpacked copy of the Boost sources (or some subset thereof). The pre-packaged versions of Boost that are available for various flavors of Linux and other platforms don't end up including Boost.Build for this reason.<br> <br> If Boost Build is a tool like Boost Regex and Boost Python etc, it should be installed too!<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> and any Jamfiles[.v2] necessary to link with those compiled<br>> libraries. These Jamfiles might necessarily be different than the <br>> ones used to build the library in the first place. They should only<br>> provide information about the required compiler flags for building<br>> code that links with the library, and the necessary library namesto <br>> link. There should be no information about how to build the library<br>> itself, since the sources aren't available.<br><br>It sounds likeyou're describing Ullrich's idea. Care to implement<br>it?</blockquote> <div><br> I find myself generally stymied by bjam/Boost.Build syntax and constructs, so I don't feel like I'm up to the job currently. The documentation for BBv2 is unfortunately not complete enough for me to learn what I need to know without help. I understand it (BBv2) is a work in progress, so an up-to-minute reference is hard to provide, but I think I need more than what is currently available to be able to implement this correctly. I'd gladly accept help from someone who knows more than me, to get me up to speed. Once I'm more comfortable with the tool I can probably make it happen.<br> <br> I'm sorry I wont be attending the SD Expo this coming week. So many meaty sessions I wanted to attend, but once again our budget has dried up.<br> </div></div><br>-- <br>Caleb Epstein<br>caleb dot epstein at gmail dot com ------=_Part_15700_17866455.1127607249036--
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk