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.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:00 UTC