[boost] Re: windows.h, and requirements

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 
        : 
            <sysinclude>$(BOOST_ROOT)
            <define>BOOST_REGEX_NO_LIB=1
            <define>BOOST_REGEX_STATIC_LINK=1
            <no-warn>$(SOURCES).cpp
        : 
            debug release
        ;

    dll boost_regex : ../src/$(SOURCES).cpp 
        : 
            <sysinclude>$(BOOST_ROOT)
            <define>BOOST_RE_BUILD_DLL=1
            <runtime-link>dynamic
            <no-warn>$(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
www.boost-consulting.com