Re: [Boost-cmake] Cmake Variable Naming

Subject: Re: [Boost-cmake] Cmake Variable Naming
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2009-12-07 14:02:10

On 12/7/09 1:39 PM, in article
F606717B-4484-4A7A-B16F-CB62172315F1_at_[hidden], "James C. Sutherland" wrote:

> On Dec 7, 2009, at 10:34 AM, Michael Jackson wrote:
> 
>> Just a comment on some of the variable naming within the Cmake files. There
>> are already some folks embedding the entire boost-cmake distribution into
>> their own projects, then using "add_subdirectory()" to try and build just
>> the parts that they need. Since Cmake does not really have a namespace I
>> think that a few of the variables may need to be prefixed with "BOOST_":
>> 
>> 
>> ENABLE_DEBUG                     ON
>> ENABLE_MULTI_THREADED            ON
>> ENABLE_RELEASE                   ON
>> ENABLE_SHARED                    OFF
>> ENABLE_SINGLE_THREADED           OFF
>> ENABLE_STATIC                    ON
>> 
>> Probably should be BOOST_ ENABLE_DEBUG.... Or Boost-Cmake may start to have
>> some unintended name clashing. Plus this helps keep all the boost variables
>> together in the Cmake-GUI and CCMake applications.
>> 
>> Thoughts? 
>> 
>> Mike Jackson
> 
> A question: why embed boost into a project rather than configuring and
> building it separately (possibly automatically from within another project)?
> Then there wouldn't really be any name clashes on the global variables, right?
> 
> You could automatically download, configure, and build boost as a TPL from
> within your build system without absorbing boost into your project.
> 
> Can you help me see why it would be better to absorb boost (and its build
> system) into your own project?

This was a question generated on the cmake mailing list which Troy just
answered in the thread entitled "building boost in subdirectory" on this
mailing list. 

Also, by having Boost a part of my own project I have a bit more control
over which versions of boost are used, or use a patched version of boost
with bug fixes that seem to keep getting missed in the main distribution. It
also makes my project easier to build because I can basically leave out the
instructions for building, installing boost, and instead just have the
instructions for my own project.
  The downside is of course the shear size of boost source. Might be a
better idea to trim boost to what is just required. For my own project I
only really need shared_ptr() header and the program_options. I could
probably try bcp to trim out what is not needed.

Mike Jackson