[CMake] CMakeifying Boost

[John Biddiscombe]

Brandon

I'm not really interested in converting the boost maintainers to cmake. 
I'm not at all interested in what they think about cmake ("Political 
buy-in" is of no concern to me). I have cmakeified so many projects that 
doing one more (even if it's quite a big one) doesn't put me off. (And I 
have the advantage that I only really care about win/linux targets). The 
trouble is that I'm distributing source code and don't want to have to 
distribute and install boost everywhere. or put endless checks in my 
code to see if it's there. CMakeifying it would solve my woes. Problem 
is it's a lot of work :(

Looks like I'm on my own ...

JB

NB. ADD_LIBRARY has a STATIC/SHARED option

> John Biddiscombe wrote:
>> I know the subject has come up a couple of times... I'm fed up with 
>> having to install boost on every system I have to compiled something 
>> on. I'd like to have a Boost utility dir in my source which will 
>> build itself along with all the other cmake controlled projects. 
>> (Preferably broken into Boost::lib1, Boost::lib2 etc etc modules)
>>
>> I've used boost a lot, but never spent much time looking at the 
>> configuration or build. Has anyone given much though to how hard it'd 
>> be to CMakeify Boost?
>> (And even if the boost maintainers aren't interested in using CMake, 
>> we could put together a distro once every few months with a latest 
>> release...)
>>
>> Anyone got any views?
> Judging by my difficulties getting Chicken to build, it'll be 
> impossible without the CVS version of CMake.  You are going to need 
> the features and bugfixes of CMake 2.3.
>
> Another issue you'll have to contend with is political buy-in.  Boost 
> is a big, stable project.  The CMake documentation is not adequate.  
> So it is very unlikely that you're going to convince the Boost guys to 
> adopt a CMake build.  Instead, you will learn all the little details 
> of CMake, have that knowledge stored up in your own head, and will be 
> solely stuck with advancing and maintaining a CMake Boost build.  It 
> will be a *lot* of work, and unless some people pop up and say, "yes! 
> yes! I really want to work on that!" nobody's going to help you.  
> Maybe you'll get some takers from around here, the people who already 
> know CMake.  I doubt you'll get any from the Boost list.
>
> Documentation is CMake's Achilles heel and will be the next thing I 
> turn my attention to, after I get Chicken working and achieve some 
> productivity with it.  I helped start the CMake-Promote list, but IMO 
> it is not worth promoting CMake until we have better documentation.  
> Also CMake 2.3 needs to ship.  There are several basic features that 
> need to be available to people, like the ability to set shared vs. 
> static flags on a per-target basis.  Can't do that in CMake 2.2.3.  I 
> would also like to see the liblib problem fully eradicated.  It is 
> embarrassing trying to explain that one to the Unix / Cygwin / MinGW 
> crowd.
>
>
> Cheers,
> Brandon Van Every
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake


-- 
John Biddiscombe,                            email:biddisco @ cscs.ch
http://www.cscs.ch/about/BJohn.php
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82