Re: [Boost-bugs] [Boost C++ Libraries] #3103: Allow using libraries without separately compiling them

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

 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
     # Without these flags, MSVC 7.1 and 8.0 crash
 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: <>
Boost C++ Libraries <>
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