[EMAIL PROTECTED] (Greg Comeau) writes:
> In article <[EMAIL PROTECTED]>,
> David Abrahams <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
