[1.41] Build files locations, try 3
Some time ago, I have raised the concern that CMakeList.txt files violate directory structure requirements. See: http://thread.gmane.org/gmane.comp.lib.boost.devel/189496/ I have pinged this a few times, see: http://permalink.gmane.org/gmane.comp.lib.boost.devel/193415 to no response. Now, with 1.41 going out soon, can we finally solve this issue? To rehash, the options we have are: 1. Move Jamfiles to the top-level directory of each lib 2. Move CMakeList.txt files to the build subdir 3. Adjust library guidelines. 4. Remove library guidelines, since they seem to be ignored. I hope we don't end up with option 4, of course. Thanks, Volodya
Vladimir Prus wrote:
Some time ago, I have raised the concern that CMakeList.txt files violate directory structure requirements. See:
http://thread.gmane.org/gmane.comp.lib.boost.devel/189496/
I have pinged this a few times, see:
http://permalink.gmane.org/gmane.comp.lib.boost.devel/193415
to no response. Now, with 1.41 going out soon, can we finally solve this issue? To rehash, the options we have are:
1. Move Jamfiles to the top-level directory of each lib 2. Move CMakeList.txt files to the build subdir 3. Adjust library guidelines. 4. Remove library guidelines, since they seem to be ignored.
I hope we don't end up with option 4, of course.
Unless somebody takes over maintenance of cmake in SVN, I'm going to remove cmake from trunk and release in the next couple of days, before 1.41 gets frozen. The reasoning was explained in previous threads. We cmakers are alive and well and have a good system for creating cmakeable distributions in the weeks after each release. -t
troy d. straszheim wrote:
Unless somebody takes over maintenance of cmake in SVN, I'm going to remove cmake from trunk and release in the next couple of days, before 1.41 gets frozen. The reasoning was explained in previous threads. We cmakers are alive and well and have a good system for creating cmakeable distributions in the weeks after each release.
Troy, I must have missed those previous threads. Can you send a link or summarize the discussion for me? I'd like to know why we're regressing our cmake efforts on trunk and release. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
troy d. straszheim wrote:
Unless somebody takes over maintenance of cmake in SVN, I'm going to remove cmake from trunk and release in the next couple of days, before 1.41 gets frozen. The reasoning was explained in previous threads. We cmakers are alive and well and have a good system for creating cmakeable distributions in the weeks after each release.
Troy, I must have missed those previous threads. Can you send a link or summarize the discussion for me? I'd like to know why we're regressing our cmake efforts on trunk and release.
This is really just a decoupling of unnecessarily coupled workflows. Once a release of boost exists, it is then efficient to tune up the cmakefiles for a boost-cmake release. One can't, for instance, right now start committing to the cmakefiles on the release branch (in anticipation of 1.41) because it is disruptive, setting off bells in an inspect script somewhere, I've done this several times already. AFAICT the fix is to maintain cmake on the trunk as well, which increases the workload significantly for no gain (nobody uses it there). Also, several bugs (cmake bugs) will likely come up in the weeks following the release, and with a separate release loop it is easy to fix them and get patch releases out. -t
(cc'ing Beman because I'd like his input on this important release issue.) troy d. straszheim wrote:
Eric Niebler wrote:
troy d. straszheim wrote:
Unless somebody takes over maintenance of cmake in SVN, I'm going to remove cmake from trunk and release in the next couple of days, before 1.41 gets frozen. The reasoning was explained in previous threads. We cmakers are alive and well and have a good system for creating cmakeable distributions in the weeks after each release.
Troy, I must have missed those previous threads. Can you send a link or summarize the discussion for me? I'd like to know why we're regressing our cmake efforts on trunk and release.
This is really just a decoupling of unnecessarily coupled workflows. Once a release of boost exists, it is then efficient to tune up the cmakefiles for a boost-cmake release.
One can't, for instance, right now start committing to the cmakefiles on the release branch (in anticipation of 1.41) because it is disruptive,
Not only is it disruptive, but it's against policy to commit directly to release.
setting off bells in an inspect script somewhere, I've done this several times already. AFAICT the fix is to maintain cmake on the trunk as well, which increases the workload significantly for no gain (nobody uses it there). Also, several bugs (cmake bugs) will likely come up in the weeks following the release, and with a separate release loop it is easy to fix them and get patch releases out.
My opinion: the cmake build system should be like other parts of boost: polished, documented, tested, reviewed, accepted, merged to trunk and then to release, and actively maintained. Distributing an experimental build system in an official boost release was probably a mistake. In that light, I must reluctantly agree that removing cmake from trunk and release is probably the right thing. Beman? My worry is that as a side project, the cmake build system will get less use and less attention. It's been 2 years since the cmake effort began, and where are we? I *really* want our users to have a standard option for building boost that integrates well with their chosen build environment. Until it is part of the official boost release, the cmake guys will be chasing tail-lights. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Not only is it disruptive, but it's against policy to commit directly to release.
I know that, I was just trying to spin it.
My opinion: the cmake build system should be like other parts of boost: polished, documented, tested, reviewed, accepted, merged to trunk and then to release, and actively maintained.
Please forgive me for saying this is a bit far-fetched. If I propose a library for inclusion and it gets rejected, fine, I still have a library. If I propose a build system (arguably more work than a typical library) and it gets rejected, I've got nothing. A new library doesn't typically require everybody to change the way they do business throughout the entire release cycle, from development to testing, and therefore doesn't encounter the inertia of the community. For that matter, I'm having trouble imagining how one would merge a build system from trunk to release. This is the same problem that provoked this discussion.
Distributing an experimental build system in an official boost release was probably a mistake.
Well we thought we would get some users, and we got lots of them on the end-users' side, but it didn't catch on with boost developers as I'd hoped. C'est la vie. I think the better way is: * A few notes in Getting Started with pointers to the cmake stuff * One root CMakeLists.txt that just prints a message on where to get boost-cmake * A link to some boost-cmake tarball area alongside the standard boost tarballs. That's the new proposal.
In that light, I must reluctantly agree that removing cmake from trunk and release is probably the right thing. Beman?
I doubt that it is necessary to agree at this point. That stuff either comes out of release or goes out broken.
My worry is that as a side project, the cmake build system will get less use and less attention. It's been 2 years since the cmake effort began, and where are we?
I don't see it that way. We have 115 people on the boost-cmake list, and a bunch of them were really helpful (thanks guys) in tuning up the build for 1.40.0, and we'll do it again in a few weeks for 1.41.0. Participation has been signficantly wider than when it was just Doug and I. There are docs, happy users, all that stuff.
I *really* want our users to have a standard option for building boost that integrates well with their chosen build environment.
They've got that. It's done. -t
troy d. straszheim wrote:
Eric Niebler wrote:
Not only is it disruptive, but it's against policy to commit directly to release.
I know that, I was just trying to spin it.
My opinion: the cmake build system should be like other parts of boost: polished, documented, tested, reviewed, accepted, merged to trunk and then to release, and actively maintained.
Please forgive me for saying this is a bit far-fetched. If I propose a library for inclusion and it gets rejected, fine, I still have a library. If I propose a build system (arguably more work than a typical library) and it gets rejected, I've got nothing.
No, you've got what you have now: a separately maintained boost-cmake distribution. If boost-cmake were reviewed and accepted, we'd have working cmake support in trunk and release also. Besides, I can't imagine a world where boost-cmake support is *not* accepted.
A new library doesn't typically require everybody to change the way they do business throughout the entire release cycle, from development to testing, and therefore doesn't encounter the inertia of the community.
This issue has never been satisfactorily addressed. Ideally, we should not require each and every boost developer to make build changes in two places. IIUC, the way it works now is that the cmake team works to keep the boost-cmake in sync with "boost-bjam." You're saying that that is working for you and your users. I don't see why that model shouldn't continue to work once boost-cmake has been merged into trunk and release.
For that matter, I'm having trouble imagining how one would merge a build system from trunk to release. This is the same problem that provoked this discussion.
Why should there be a problem? Changes to bjam are first made on trunk and then merged to release, aren't they? What makes cmake different? It's an honest question.
Distributing an experimental build system in an official boost release was probably a mistake.
Well we thought we would get some users, and we got lots of them on the end-users' side, but it didn't catch on with boost developers as I'd hoped. C'est la vie.
You seem to be laying the blame for broken cmake support on trunk and release at the feet of all boost developers everywhere. I don't think that's fair.
I think the better way is:
* A few notes in Getting Started with pointers to the cmake stuff * One root CMakeLists.txt that just prints a message on where to get boost-cmake * A link to some boost-cmake tarball area alongside the standard boost tarballs.
That's the new proposal.
That could certainly work, but I still don't see why that is better. It's not less work, is it?
In that light, I must reluctantly agree that removing cmake from trunk and release is probably the right thing. Beman?
I doubt that it is necessary to agree at this point. That stuff either comes out of release or goes out broken.
Fair enough.
My worry is that as a side project, the cmake build system will get less use and less attention. It's been 2 years since the cmake effort began, and where are we?
I don't see it that way. We have 115 people on the boost-cmake list, and a bunch of them were really helpful (thanks guys) in tuning up the build for 1.40.0, and we'll do it again in a few weeks for 1.41.0. Participation has been signficantly wider than when it was just Doug and I. There are docs, happy users, all that stuff.
Excellent! Glad to hear it.
I *really* want our users to have a standard option for building boost that integrates well with their chosen build environment.
They've got that. It's done.
"Done" is a matter of perspective. In my dream world -- and unless I'm convinced otherwise -- it's done when it's merged to release. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
troy d. straszheim wrote:
Eric Niebler wrote:
Not only is it disruptive, but it's against policy to commit directly to release.
I know that, I was just trying to spin it.
My opinion: the cmake build system should be like other parts of boost: polished, documented, tested, reviewed, accepted, merged to trunk and then to release, and actively maintained.
Please forgive me for saying this is a bit far-fetched. If I propose a library for inclusion and it gets rejected, fine, I still have a library. If I propose a build system (arguably more work than a typical library) and it gets rejected, I've got nothing.
No, you've got what you have now: a separately maintained boost-cmake distribution. If boost-cmake were reviewed and accepted,
I think you have left out "polished, documented, tested" :-). One data point is transition to Boost.Build V2. I've spend a couple of months doing nothing but checking test results with V1 and V2 and making sure no problem is introduced by V2 itself. Even though the overall health of tests is better now, it seems reasonable to require that any alternative build system be similarly validated, and it will take similar amount of time. There's no magic way to do this overnight.
we'd have working cmake support in trunk and release also.
Besides, I can't imagine a world where boost-cmake support is *not* accepted.
I don't think there was any explicit decision to go with CMake -- even if we ignore Boost.Build for now, it's not clear that CMake is the best build system when compared with other alternatives. Therefore, any such discussion makes sense only if specific alternatives are ready -- as deemed by their authors. - Volodya
Eric Niebler wrote:
troy d. straszheim wrote:
Eric Niebler wrote:
My opinion: the cmake build system should be like other parts of boost: polished, documented, tested, reviewed, accepted, merged to trunk and then to release, and actively maintained.
Please forgive me for saying this is a bit far-fetched. If I propose a library for inclusion and it gets rejected, fine, I still have a library. If I propose a build system (arguably more work than a typical library) and it gets rejected, I've got nothing.
No, you've got what you have now: a separately maintained boost-cmake distribution. If boost-cmake were reviewed and accepted, we'd have working cmake support in trunk and release also.
The point was that the boost build system is only usable for building boost, unlike, say, a regex library. You can't pack it up and take it elsewhere.
A new library doesn't typically require everybody to change the way they do business throughout the entire release cycle, from development to testing, and therefore doesn't encounter the inertia of the community.
This issue has never been satisfactorily addressed. Ideally, we should not require each and every boost developer to make build changes in two places. IIUC, the way it works now is that the cmake team works to keep the boost-cmake in sync with "boost-bjam." You're saying that that is working for you and your users. I don't see why that model shouldn't continue to work once boost-cmake has been merged into trunk and release.
As I mentioned, we sync up with 'boost-bjam' after each release, when we know that everything builds. This is efficient and serves us well. Maintaining cmake on trunk and release would be vastly more effort, but if you had more people you could do it.
For that matter, I'm having trouble imagining how one would merge a build system from trunk to release. This is the same problem that provoked this discussion.
Why should there be a problem? Changes to bjam are first made on trunk and then merged to release, aren't they? What makes cmake different? It's an honest question.
I think the crucial difference is that everybody maintains their own jamfiles. If somebody merges to release without fixing their cmakefiles, and then modifies trunk, you could be hosed. OTOH if everybody maintained their own cmakefiles, then I agree it could work the same way.
Distributing an experimental build system in an official boost release was probably a mistake.
Well we thought we would get some users, and we got lots of them on the end-users' side, but it didn't catch on with boost developers as I'd hoped. C'est la vie.
You seem to be laying the blame for broken cmake support on trunk and release at the feet of all boost developers everywhere. I don't think that's fair.
I don't know where you get that. I'm not blaming a bunch of people who just minded their own business. I miscalculated, pushed for putting cmake on the trunk, I made the commits and I'm admitting it.
I *really* want our users to have a standard option for building boost that integrates well with their chosen build environment.
They've got that. It's done.
"Done" is a matter of perspective. In my dream world -- and unless I'm convinced otherwise -- it's done when it's merged to release.
<shrug> -t
participants (3)
-
Eric Niebler -
troy d. straszheim -
Vladimir Prus