[cmake] revision 50756 failed to merge some file properties
Hi, this is a repost of a message that went unnoticed three months ago: http://lists.boost.org/boost-cmake/2009/06/0592.php and that's causing problems when merging CMake-specific stuff from trunk to release, as discussed at: http://lists.boost.org/Archives/boost/2009/08/154996.php http://lists.boost.org/Archives/boost/2009/08/155003.php CMakeLists.txt and related files in trunk do have a "svn_keywords" property with value "Id", while the counterparts in the release branch are missing this property. I guess this was an oversight when applying revision 50756: https://svn.boost.org/trac/boost/changeset/50756 Unless fixed, this is going to pop up again when the release manager prepares for 1.41. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN M. LOPEZ MUÑOZ wrote:
Unless fixed, this is going to pop up again when the release
manager prepares for 1.41.
This should be fixed in r56113, apologies about this and thanks for the notice. I suppose there is some question whether it makes sense to keep this stuff in release/trunk or not, as it is apparently only used by end users and packagers; I take no pleasure in making the release process more difficult than it is; there is no point in maintaining cmakefiles on the trunk if they are not used by people working on/against the trunk; the 1.40 release didn't work out of the box, the patched 'cmakeable' 1.40 distribution is elsewhere. -t
troy d. straszheim <troy <at> resophonic.com> writes:
JOAQUIN M. LOPEZ MUÑOZ wrote:
Unless fixed, this is going to pop up again when the release manager prepares for 1.41.
This should be fixed in r56113, apologies about this and thanks for the notice.
Thank you for taking care.
I suppose there is some question whether it makes sense to keep this stuff in release/trunk or not, as it is apparently only used by end users and packagers; I take no pleasure in making the release process more difficult than it is;
IMHO if some specific material (CMake stuff in this case) is going to be delivered, then it *has* to be deployed and maintained in trunk just as anything else; this particular quirk was just that, a quirk, I wouldn't extract far-fetched consequences from it.
there is no point in maintaining cmakefiles on the trunk if they are not used by people working on/against the trunk; the 1.40 release didn't work out of the box, the patched 'cmakeable' 1.40 distribution is elsewhere.
I guess what's caused that problem is that CMake-stuff is not being automatically tested like the rest of material in Boost. If you manage to get a toolset to build with CMake rather than the standard Boost.Build, the CMake material would be as easily maintainable as any other Boost feature. Whether it has to be you or the authors who respond to failures, this is probably another matter. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquin M Lopez Munoz wrote:
troy d. straszheim <troy <at> resophonic.com> writes:
JOAQUIN M. LOPEZ MUÑOZ wrote:
Unless fixed, this is going to pop up again when the release manager prepares for 1.41.
This should be fixed in r56113, apologies about this and thanks for the notice.
Thank you for taking care.
I suppose there is some question whether it makes sense to keep this stuff in release/trunk or not, as it is apparently only used by end users and packagers; I take no pleasure in making the release process more difficult than it is;
IMHO if some specific material (CMake stuff in this case) is going to be delivered, then it *has* to be deployed and maintained in trunk just as anything else; this particular quirk was just that, a quirk, I wouldn't extract far-fetched consequences from it.
From my perspective, it isn't a quirk; When 1.41 time rolls around, it will make sense to tune up the cmakefiles for release, and it will still not make sense to tune up the cmakefiles on the trunk, where noone uses them. I'm not about to ask library authors to maintain two build systems, nor to ask them to switch to cmake; however I think the cmakeable distributions are useful to a certain group, and it is easy and efficient to prepare these asynchronously. -t
troy d. straszheim escribió:
Joaquin M Lopez Munoz wrote:
IMHO if some specific material (CMake stuff in this case) is going to be delivered, then it *has* to be deployed and maintained in trunk just as anything else; this particular quirk was just that, a quirk, I wouldn't extract far-fetched consequences from it.
From my perspective, it isn't a quirk; When 1.41 time rolls around, it will make sense to tune up the cmakefiles for release, and it will still not make sense to tune up the cmakefiles on the trunk, where noone uses them. I'm not about to ask library authors to maintain two build systems, nor to ask them to switch to cmake; however I think the cmakeable distributions are useful to a certain group, and it is easy and efficient to prepare these asynchronously.
Would it be possible to set up a regression runner that uses CMake instead of Boost.Build so that problems with CMake are treated the same way as "regular" problems? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
joaquin@tid.es wrote:
troy d. straszheim escribió:
Joaquin M Lopez Munoz wrote:
IMHO if some specific material (CMake stuff in this case) is going to be delivered, then it *has* to be deployed and maintained in trunk just as anything else; this particular quirk was just that, a quirk, I wouldn't extract far-fetched consequences from it.
From my perspective, it isn't a quirk; When 1.41 time rolls around, it will make sense to tune up the cmakefiles for release, and it will still not make sense to tune up the cmakefiles on the trunk, where noone uses them. I'm not about to ask library authors to maintain two build systems, nor to ask them to switch to cmake; however I think the cmakeable distributions are useful to a certain group, and it is easy and efficient to prepare these asynchronously.
Would it be possible to set up a regression runner that uses CMake instead of Boost.Build so that problems with CMake are treated the same way as "regular" problems?
Why should this be the case? CMake is experimental, and it seems wrong to promote problems with experimental anything to regular problems. I think we also have SCons setup for Boost -- should that be also regression tested, and problems treated as regular? - Volodya
Vladimir Prus <vladimir <at> codesourcery.com> writes:
joaquin <at> tid.es wrote:
Would it be possible to set up a regression runner that uses CMake instead of Boost.Build so that problems with CMake are treated the same way as "regular" problems?
Why should this be the case? CMake is experimental, and it seems wrong to promote problems with experimental anything to regular problems.
From my point of view, anything that's released along with Boost should be as thoroughly tested as possible. If CMake support is indeed to be given experimental status, then it'd be better to ship its stuff separately.
I think we also have SCons setup for Boost -- should that be also regression tested, and problems treated as regular?
What's the alternative, not testing it or not dealing with the arising problems? Joaquín M López Muñoz Telefónica, Invesgitación y Desarrollo
Joaquin M Lopez Munoz wrote:
Vladimir Prus <vladimir <at> codesourcery.com> writes:
joaquin <at> tid.es wrote:
Would it be possible to set up a regression runner that uses CMake instead of Boost.Build so that problems with CMake are treated the same way as "regular" problems?
Why should this be the case? CMake is experimental, and it seems wrong to promote problems with experimental anything to regular problems.
From my point of view, anything that's released along with Boost should be as thoroughly tested as possible.
I believe that CMake was added to trunk, and release branch, for no other reason than to help CMake folks with development. It was not meant to have any other consequences, from what I understand.
If CMake support is indeed to be given experimental status,
Well, it's officially experimental from the start :-)
then it'd be better to ship its stuff separately.
I have no comment on this.
I think we also have SCons setup for Boost -- should that be also regression tested, and problems treated as regular?
What's the alternative, not testing it or not dealing with the arising problems?
Well, anybody is free to setup a regression tester -- including for any experimental branch. It's only becomes a concern if any failures from such regression tester get mixed with regular test result (requiring an extra effort to triage) or require extra work on part of developers. - Volodya
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Wednesday, September 09, 2009 2:47 PM Subject: Re: [boost] [cmake] revision 50756 failed to merge some fileproperties
joaquin@tid.es wrote:
Would it be possible to set up a regression runner that uses CMake instead of Boost.Build so that problems with CMake are treated the same way as "regular" problems?
Why should this be the case? CMake is experimental, and it seems wrong to promote problems with experimental anything to regular problems. I think we also have SCons setup for Boost -- should that be also regression tested, and problems treated as regular?
Hi Volodya, there is a differnce: Boost.CMake is already delivered with the Boost releases, even if not reviewed. Vicente
vicente.botet wrote:
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Wednesday, September 09, 2009 2:47 PM Subject: Re: [boost] [cmake] revision 50756 failed to merge some fileproperties
joaquin@tid.es wrote:
Would it be possible to set up a regression runner that uses CMake instead of Boost.Build so that problems with CMake are treated the same way as "regular" problems?
Why should this be the case? CMake is experimental, and it seems wrong to promote problems with experimental anything to regular problems. I think we also have SCons setup for Boost -- should that be also regression tested, and problems treated as regular?
Hi Volodya,
there is a differnce: Boost.CMake is already delivered with the Boost releases, even if not reviewed.
As I've already mentioned, the reason it was merged to trunk and then release for no other reason than helping cmake folks. You can check the email archives if you don't believe me. So if the fact that it's on trunk is used to make work, I'd suggest that it be un-added. - Volodya
participants (6)
-
Joaquin M Lopez Munoz -
JOAQUIN M. LOPEZ MUÑOZ
-
joaquin＠tid.es
-
troy d. straszheim -
vicente.botet -
Vladimir Prus