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