On Wed, Oct 27, 2010 at 2:38 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2010-10-26 17:53-0400 Bill Hoffman wrote: > >> The policy mechanism might not be ideal but in a year or so, all of this >> would go away, and the meantime the patches you have to maintain for cygwin >> ports would become trivial. The patch would basically have a set cmake >> version at the top. I thought the command line option was a nice >> compromise. > > Bill, as somebody associated with a software package (PLplot) which > already works on Cygwin, I think the policy mechanism is the ideal way > to handle this requested change. I do believe the Cygwin packagers > when they say the change will make a lot more projects build without > issues on Cygwin, but it is also extremely likely their preferred > solution (breaking backwards compatibility for cmake) would also break > currently working builds (such as the PLplot one) on Cygwin. > > I sympathize with the frustrations of the Cygwin packagers at the > slowness with which this issue has been dealt with, but OTOH, I am not > sure they completely understand the neat resolution of the issue that > you are now offering with a policy-based approach to the requested > change. Thus, I suggest you just go ahead and implement that preferred > solution without further frustrating delays. Then publish cookbook > instructions about the one-line change that needs to be made in the > top-level CMakeLists.txt file of each currently non-working Cygwin > project (but not the working ones like PLplot) in order for the new > policy to be recognized. Ideally, upstream projects that currently > don't build on Cygwin will adopt this solution, but if they are slow > in doing that, it should not be too difficult for the Cygwin packagers > to implement a sed (or whatever) script to do the required one-line > changes in the top-level CMakeLists.txt files for each package in an > automatic fashion.
As someone who packaged software for Gentoo Linux for many years I can sympathize with your frustration when something is not corrected in a timely fashion. I don't know much about the background of this particular case, but I would hope that you would choose to work with Bill rather than patch CMake and circumvent his efforts to fix this issue. If this results in a one line patch to Cygwin packages in the short term, which can be removed in the longer term, that would seem like a reasonable solution to the problem. Breaking backwards compatibility could potentially break all of the packages people got working on Cygwin with CMake, and that would be far worse. Disclaimer: I am also a Kitware employee, but before I came here I worked in open source for many years as part of larger projects such as Gentoo, KDE and Avogadro. I for one like the policy mechanism, as it allows CMake to move forward while not breaking existing builds. As a packager I would never intentionally change the default behavior of a project, effectively forking the project. If you chose to take such rash action I would also avoid cygwin in the future. Marcus _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake