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 05:45:06

#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 eckhardt):

 Replying to [comment:5 Jonathan Wakely <jwakely.boost_at_[hidden]>]:
 > Replying to [comment:4 eckhardt]:
 > > > "it's up to the user to make sure that it's exactly done once"
 > > > This seems like a supremely bad idea to me, and so does asking users
 to #include "something.cpp"
 > >
 > > Why? It's not complicated, it doesn't give erratic and hard-to-
 diagnose runtime behaviour when done wrong.
 >
 > Including a {{{.cpp}}} file is unnecessarily unconventional.  It's not
 innovative, it's just confusing and makes people wonder what's going on.
 > I would have fewer objections if you suggested calling it
 {{{compile_inplace.inl}}} or {{{compile_inplace.hpp}}} or almost
 *anything* else.

 The suffix 'inl' suggest to me that it contains some definitions of inline
 functions to me, the suffix 'hpp' suggests declarations, but neither is is
 the case. It really is a source file (you could compile it separately), so
 the 'cpp' is IMHO deserved. Also, if people stumble across an included
 'cpp' file and as a result start to think, that is a good thing, because
 noticing that this is not just one more include is important for using it
 correctly. The point is that the thing does something unconventional and
 the name of the file properly reflects that.

 >> One important thing however is that this file ideally doesn't change
 name or location, which can't be said about the implementation files of a
 library within Boost.
 >
 > If there's a single file which users can compile directly and its name
 changes, you need to change your {{{#include}}} directive to use the new
 name.  Including it doesn't insulate you from that name change.

 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.

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

 > [bjam] could be extended to generate the necessary commands as well as
 (or instead of) building the separate libraries.

 bjam doesn't support my compiler (I'm not kidding, I'm working with a
 cross compiler for an embedded target!) or I'm not using compatible
 settings for my code, so now I have to find out how to tell bjam about
 these specialties I'm using.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/3103#comment:6>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.