Re: [boost] [CMake] what to do now?

Subject: Re: [boost] [CMake] what to do now?
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-14 09:06:17

> On Apr 14, 2016, at 3:54 AM, Stephen Kelly <hello_at_[hidden]> wrote:
> 
> P F wrote:
> 
>> If the users wants the latest boost(as system level package managers are
>> usually behind) or the user is cross-compiling. Where I used to work, we
>> always built boost because of cross-compiling. 
> 
> Ok, so you're ignoring boost users who don't fit the same mold as you. You 
> should make this more explicit in your plan. (I also think you should expand 
> your mind a bit).
> 
> 
>>> If you port a library to cmake, will people using boost from the ubuntu
>>> package get the cmake package files?
>> 
>> I don’t know the details with that because I usually always use pkg-config
>> over the cmake package files. 
> 
> Oh, you don't understand.
> 
>> I would assume so, since pkg-config files
>> are available from ubuntu packages(not boost packages but other packages
>> provide them).
> 
> And where would the cmake files come from? How would they appear in the 
> packages? They have to be generated, remember. Are you going to make cmake a 
> hard requirement just to generate some files?

If a boost library is being built already with cmake, of course it will use cmake. 

> 
>> I see it happening on a per-library basis at first rather than as whole
>> which is much more complicated. 
> 
> I think you need a much more specific plan. I think you don't understand the 
> problem yet.
> 
>> So then when the user wants Boost.Filesystem it can download and build the
>> libraries needed just for Boost.Filesystem. 
> 
> I think you need to expand your mind beyond 'the user downloads the source 
> and builds it'. You are missing entire worlds.

I think you are missing entire worlds as well. Everywhere I have worked, we always built boost from source.

> 
>> Then libraries that fail to move forward due to lack
>> of maintainers or refusal to deal with cycles would then be left behind.
> 
> And hitting conclusions like this is where you will hit community friction 
> eventually I'm sure.
> 
>>> 
>>> I really wonder what a viable plan along the lines you are thinking would
>>> look like.
>>> 
>>> In my mind, the only way to make the boost+cmake experience better for
>>> users in a finite time frame is to generate the package files with
>>> boost.build. That way users of package managers will get the cmake files
>>> and they will be useful.
>> 
>> It would make the experience better in the short-term.
> 
> I don't know what you mean here. My suggestion improves the experience 'in a 
> short time frame'.
> 
> Anyway, you have made clear that only 'people building top of tree from 
> source as part of building their own stuff' is the scope of what you're 
> interested in. You have also made clear that you don't know what cmake 
> packages are,

I never said that. I said I didnt know the details, and by details I meant the details of debian packaging. I do know what the cmake package files are.

> and you have said you never use them. You don't seem to want 
> to look outside your own bubble.
> 
> Given those points it's clear to me that you didn't understand my 
> boost.build mailing list post.
> 
> Thanks,
> 
> Steve.
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost