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
 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.