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:17:26

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

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

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

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

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

 Note to self: Add an FAQ section in the README!

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