$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-13 16:55:37
----- Original Message -----
From: "Steve M. Robbins" <steven.robbins_at_[hidden]>
> I hope you appreciate, therefore, that someone steeped in the unix
> world, having years of experience using auto-* tools, can find JAM
> just as impenetrable on the first go.
Absolutely. Jam isn't exactly gentle, but we're working to make it lots
better. The build system redesign effort currently underway should make
things a bit better. As for the Jam core language, well, it's esoteric but
adequate.
> I'm using linux (Debian) and the 1.26.0 release of BOOST.
>
> I have been able to get jam built and running, and it builds several
> flavours of static libraries for the regex, thread, and python
> libraries. For regex, I also end up with a shared library, but there
> is no shared lib for the other two.
The current CVS state builds a shared library for Python, which results in
much smaller generated extension modules ;-)
Whether any library is built as static or shared is up to its designer. I
think Bill Kempf has good reasons not to build threads as a shared lib, but
I'm not sure of that.
> There is a Jamfile in libs/graph/build, but the graph project is not
> a subinclude of the top-level Jamfile. Intentional or oversight?
You'll have to ask the BGL guys. Oh, maybe you are trying to ask them. I
don't know the answer, though.
> The lack of shared lib for the thread and python parts of boost is a
> question of someone getting around to writing the jam rules? Or is it
> that they ought not to have one?
See above.
> The shared library file for regex lacks a SONAME. I poked around in
> the jam stuff to fix this. It appears that jam (or boost?) shares the
> same "Link-action" rule for both programs and shared libraries. Surely
> there ought to be different rules for building a program versus building
> a shared object?
That's up to the toolset. Often the build actions are similar enough that
it's best to use a single build action with different variable settings. The
third argument to Link-action is the target type (EXE, DLL, or PYD). You can
write the Link-action rule to dispatch to different rules if you like.
> Is there any BOOST policy on library versioning and SONAMES? I'm
> building packages for Debian. The last packages that were built for
> Debian were based on BOOST 1.21, and they did appear to use SONAMES.
Sorry, I'm a bit ignorant. Can you explain what SONAMES are supposed to do?
> However, all that mechanism (e.g. the makefiles) appears to have been
> purged in the move to JAM. True?
In most cases there are still Makefiles lying around.
> Should I forget about packaging
> shared libs, and ship only the .a files?
Definitely not. Let us know what needs to be changed and we'll figure it
out.