[C++-sig] Re: help building hello world example on Debian

[David Abrahams]

Faheem Mitha <faheem at email.unc.edu> writes:

>>> 1) Please clarify which files correspond to the boost build system. 
>>
>> Where should that be clarified?
>
> I think the tutorial 

The Boost.Python tutorial or the Boost.Build tutorial?

> would be a good place to say something about this. Bear in mind that
> most people will pass that way at least at the beginning, and at
> least some of them will not be familiar with the boost build system.

If you could specifically point to a place to add text, and perhaps
suggest the text, that'd be a big help.

>>> If these tools/build/v1 should be part of a binary installation,
>>> please say so. 
>>
>> It depends on your expectations of a binary installation, I guess.
>> If you want to do all your building with other build systems, you
>> probably don't need them.  That said, we recommend Boost.Build, at
>> least in order to see the proper command-lines.
>
> Well, to clarify, I mean you should be able (at least for a modern
> Linux distribution) to install packages (using rpm, apt, emerge
> whatever) all necessary files into the system to enable such
> extensions to build. The word binary may be misleading in this
> context.

In theory you don't need Boost.Build for that, just like you don't
need any particular build system to put together a program that uses,
say, Qt... or Python.  For many Python extension applications, having
distutils helps.  Likewise, Boost.Build helps.  A lot.

> Is it correct to say that the files in build/v1 would be enough by
> themselves for the extension to build against? That is my impression,
> since boost-build.jam in the libs/python/example directory is pointing
> to it, and nothing else is the build process is looking for other
> files in the Boost installation.

I don't know what other files may be missing from the Boost tree in
your distro, so I can't rightly say.  That said, yes, tools/build/v1
contains all the build system files needed for Boost.Build v1.

> However, it seems possible, since compilation took so long, that the
> build also compiled files elsewhere in the sources as part of the
> extension build. 

I don't know what you mean.  It's very likely to have compiled the
Boost.Python library out of sources in the libs/python/src directory.

> If so, this would make things more difficult. I'd appreciate
> information about this.

Keep in mind that Boost is designed to be delivered as a complete
tree.  You can download a copy from our site or browse the current CVS
state at http://www.boost-consulting.com/boost.  Packagers that split
it up in various ways may be leaving out pieces.

>>> It is is not reasonable to expect people to build against a
>>> complete copy of the boost sources.
>>
>> Actually, that is the expectation.
>
> Surely a complete source copy is not necessary if only certain files
> are required.

Not neccessarily neccessary, but we're not trying to figure out which
parts you need and which you don't.

>>> 2) Also, all this v1/v2 stuff is unclear. My impression is that v1 is
>>> the "stable" version of the build system, and v2 is the unstable one,
>>> but it would be useful to say something about this explicitly.
>>
>> Where should that be stated?
>
> Again, the tutorial would be a good place.

More specifics please.

>> I don't think we can quite do that, since individual compilers may
>> need config info, however we can make reference to the toolsets web
>> pages that document it.
>
> In Jamrules, mention
>
> path-global PYTHON_ROOT : /usr ;
> path-global PYTHON_VERSION : 2.3 ;

http://boost-consulting.com/boost/libs/python/example/Jamrules
OK?

> at least, these will frequently need to be changed.
>
> Possibly also add a line for 
>
> $(ALL_LOCATE_TARGET)
>
> since people often want to control where their built binaries will end
> up. I know I do.

Sheesh, OK.  This is beginning to turn into a mini Boost.Build
tutorial.

> None of these are compiler/tool-chain dependent config options, as
> far as I can see.
>
> You already mention python config stuff in Jamrules (in
> libs/python/example/Jamrules), but put in the actual lines to be
> used so people don't have figure out the exact syntax.

But people will have to put in different values.

> Well, distutils is the official build tool for Python extensions, as
> I understand it. So it is not quite the same as make or scons etc.

make is the official build tool for RedHat systems.

> A few questions.
>
> * Is work underway to add the necessary C++ support to distutils?

I don't know.

> * Once there is sufficient support, would you consider officially
> supporting distutils?

I'd consider it.

> * Is there anything you can point me to which discusses distutil's
> deficiencies wrt to C++?

Not without googling, which you can do yourself.

HTH,

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com