Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-06-17 09:42:38

comeau_at_[hidden] (Greg Comeau) writes:

> In article <ubrwxkeeb.fsf_at_[hidden]>,
> David Abrahams <jamboost_at_[hidden]> wrote:
>>gclbb-jamboost_at_[hidden] writes:
>>> I've presented this at a higher level, and hence as a build
>>> question, because, it seems
>>> the libs are being built in different ways across tools
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>I don't understand the meaning of this. Libraries are built in
>>different ways. Some libraries have build instructions which use
>>tool-specific adjustments to build options, to work around bugs or
>>enable required features.
> When you say "build instruction", what is that?

A target specification in a Jamfile. Here are two examples:

    lib boost_regex : ../src/$(SOURCES).cpp
            debug release

    dll boost_regex : ../src/$(SOURCES).cpp
            debug release

> Is boost/tools/build/como-win32-tools.jam a build instruction?

No, that's a toolset file which describes how to map build features
onto command-lines for a particular toolset.

> I attempted to touch on this I think in my first post.
> I realize different products will for instance use
> different linkers, or, say, allow shared libraries or not, etc.
> And those seem neutral ways to build the same library
> in different ways. But when the same criteria _on the code_
> is different, then I think it's a different thing.

IIUC you are saying there are some compiler options which are
"neutral" and some which are not. I'm not sure I buy that argument,
but even if I do, I'm still left with... so what?

>>> which seems then to transcend any particular libraries concerns.
>>> I'm posting this to know if my saying this is totally unfounded.
>>Can't say until I understand what you're asking
> It seems to me that bugs and such are one thing, and that sometimes
> the bugs interfere, but it also seems to me that when completely
> different dialects of C++ are being used, it seems like odd
> comparisons. As mentioned in another post, for instance, running
> VC++ with /Za and then again without /Za... well, not only can the
> results be completely different but the underlying premise of the
> builds are as well.

We're not comparing compilers here; we're just testing which
compilers you can expect a particular library to work with.

IIUC people want to be able to use como without extensions for
microsoft bugs because they want to be sure they're not
*unintentionally* relying on non-portable behavior (other kinds of
extensions like __declspec are used much more thoughtfully), but
that's really a separate issue from what the tests represent.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at