Subject: Re: [Boost-bugs] [Boost C++ Libraries] #3103: Allow using libraries without separately compiling them
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2009-06-09 09:16:59
#3103: Allow using libraries without separately compiling them
-------------------------------+--------------------------------------------
Reporter: eckhardt | Owner:
Type: Feature Requests | Status: new
Milestone: To Be Determined | Component: Building Boost
Version: | Severity: Problem
Resolution: | Keywords:
-------------------------------+--------------------------------------------
Comment(by Jonathan Wakely <jwakely.boost_at_[hidden]>):
Replying to [comment:6 eckhardt]:
> There is thread.h and thread.cpp in version X. In version X+1 there is
thread.h and thread_posix.cpp and thread_win32.cpp. Using a separate
source file to include all real sources allows library maintainers to
rearrange their code as they see necessary without breaking that. IOW,
this single source file provides a level of indirection.
Yes, obviously it provides a level of indrection, but that's not an
argument in favour of using {{{#include}}} for a {{{.cpp}}} file.
Compiling the {{{.cpp}}} file directly would still allow the sources to be
moved around.
> > What command should be used to compile the file that has that include?
Why not just
> > use that command to compile the file directly? Including it in
another file first doesn't
> > insulate you from having to know exactly how to build the file.
>
> You should get an #error if you do it wrong, along with a comment that
tells you how that is wrong. Actually, there was very little to do in
order to make this work. Also, and that is an important point, I want to
build the sources in exactly the same configuration as the user's sources.
The reason is that this makes different ABIs a non-issue. Testing a new
version of Boost, a different compiler or just incompatible compiler
settings doesn't require you to do anything further to assure binary
compatibility.
You can only use #error for something detectable by the preprocessor, so
won't work for many compiler switches (maybe most of them.)
As I said, the build options used for the user's sources may not be
suitable for the library. I don't just mean ABI-changing options,
Boost.Graph has these settings:
{{{
# # Intel compiler ICEs if we turn optimization on
<toolset>intel-vc71-win-9.1:<optimization>off
# Without these flags, MSVC 7.1 and 8.0 crash
<toolset>msvc-7.1:<cxxflags>-GR-
<toolset>msvc-8.0:<cxxflags>-GR-
}}}
Or have a look at {{{src/iostreams/build/Jamfile.v2}}} and tell me that
making a user duplicate that logic in their own build system makes it
easier, bearing in mind that you have been arguing the case for users who
can't even find and compile a source file, but only use {{{#include}}}!
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/3103#comment:8> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:00 UTC