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-08 17:55:41

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

 > > What is the advantage of asking users to #include a file and then
 compile it, rather
 > > than just compiling it?"
 >
 > There is none per se. 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.  Besides,
 if there's a single source file intended for users to compile themselves
 then I would expect it to be fairly stable, like the headers users are
 already meant to include.

 > > Wouldn't it achieve the same goals, without being needlessly
 unconventional, to make
 > > it easier for users to compile the sources into their app directly?"
 >
 > Actually, I don't care about being unconventional, I call that
 innovation. What I do care about is making it easy for users to compile
 the sources into their application, and I can't find an easier way than
 "#include <boost/foo/compile_in_place.cpp>". Seriously, if you can propose
 a way that is as universal and as easy to use I'm happy to redraw my
 request, but up to now I don't see one.

 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.

 >
 > Further:
 >  * The proposal to use a makefile fragment is also not enough. Some
 people don't even know how to run their compiler via commandline, let
 alone what a makefile is, because they are using a different build system.

 I don't care about people who don't bother to lean about their build
 system :-)

 I gave the example of a makefile fragment as an example of how it would
 work for people using makefiles.  For people using a different build
 system, different methods would be needed for building and linking to the
 object.

 >  * Using bjam suffers the same problems and I personally haven't found
 my way around bjam yet, even after using it it still seems very
 intimidating and complicated to me. Maybe that's just me though.

 I don't like bjam, but it's already used by boost and could be extended to
 generate the necessary commands as well as (or instead of) building the
 separate libraries.  Whether bjam gets runs directly, or via cmake, or
 some other method, doesn't matter.  It could print out the necessary
 commands and they could be incorporated into users' build systems, even if
 they have to ask a responsible adult to help them.

 >  * Providing build integration fragments and instructions for everything
 including the kitchen sink is a maintenance nightmare because it is next
 to impossible to automatically test it.

 But it's no worse than your proposal, which offers no way for users to
 know what commands to use to build {{{compile_inplace.cpp}}} (or the file
 that includes it, in your proposal.)

 >  * Copying the commands into their own build system is also not really
 easy. The problem is that you need to refer to some files that are found
 via the include path and then fed to the compiler. Several IDE build
 systems don't support variable substitution let alone accessing the
 configured paths of the builtin compiler. #include on the other hand does
 without any further work.

 I don't care about crappy IDEs any more than I care about programmers who
 don't know how to compile code :-)

 However, I finally see a benefit to your proposal:  users who do not know
 where the boost headers are located, they can find the
 {{{compile_inplace.cpp} file via the existing include paths in their build
 system.

 >  * Why require a second build step for a separately compiled file? With
 my proposal, I can compile a program using e.g. Boost.Thread with a single
 compiler invocation and the only thing I have to adjust is the include
 path, which I have to adjust anyways and add a well-known stanza to the
 source file.

 That's not true.  If the compile_inplace.cpp file needs particular
 compiler settings (e.g. to increase template instantiation depth, or to
 enable pthreads, or to undefine MIN/MAX macros, etc.) then it is not
 sufficient just to include it in another file and build as normal - the
 normal build process might not be suitable for the boost library.

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