--- Mer 27/10/10, Alexander Neundorf ha scritto:
> > >> I suppose one other options is something like > this: > > >> > > >> "Warning: CMake has be forced to break > backwards > > >> compatibility by the cygwin ports > maintainers, we apologize > > >> if this broke your code. If your code does > not compile, then > > >> set the cygwin policy to OLD, or add > if(CYGWIN) set(WIN32 1) > > >> to your code." > > > > > > I am not familiar with the cmake policy stuff. > > > But it seems a workable solution. > > > > In my, not so humble, opinion it is the only solution > if you insist on > > changed behavior. > > I agree too. > As a cmake developer, keeping backward compatibility is one > of the major goals > of cmake. > Just changing the behaviour will most probably break stuff > which is working > now. > Who uses cmake for building for cygwin, can test for > if(UNIX) > or > if(CYGWIN) > > To differentiate between CYGWIN and a "real" native UNIX he > can also test for > if(WIN32), e.g. to check whether some other Windows stuff > exists on the > system (which does). > This seems like a good and sensible choice to me. > > If a cmake-based project wants to support cygwin, it must > be aware of that. > If a project which was developed on e.g. Linux is ported to > Cygwin, some > patches may be necessary to that program. I think that's > normal when porting > software to another OS. > > Alex Dear Alex, thanks for you comments, but I would like to highlight one missing point on your reasoning. We don't want to limit ourself to the packages where the developer thought of cygwin as a defined target, we are potentially interested to all packages that have a generic unix as target. Most of the projects ignore what cygwin is; their developers write CMakeLists.txt with IF(WIN32) conditions for windows and IF(UNIX) for unix. Trying to build such programs on cygwin with both the two conditions is doomed to failure. To port such package, that are by large the majority, on cygwin we have 3 options: 1) propose a long patch to every upstream, highlighting the mistake they did forgetting us. Considering the easy success we have to convince cmake developers, this road is more a less a nightmare for any cygwin package maintainers. 2) use a cmake package outside the cygwin distro that don't set WIN32 for cygwin. It is my current solution; but it is not optimal for cygwin as I would like that also others could build the packages as I am doing. Should every cygwin maintainer have its own cmake package ? 3) convince the current cmake cygwin package maintainer, that is also a cmake developer, that we need a way to unset WIN32. How ? I am open to proposal, except case 1, please. I understand that making a unconditional WIN32 switch could break some package, but I suspect they are much less than Bill is afraid of. After all I built both CMAKE and VTK with WIN32=0. But I admit that eventually my build is different from the original aim of their developers. Having a switch/policy to define the cygwin behaviour, is a possible solution that would allow us to build the majority of unix package as smooth as possible also for cygwin and allow current developers using cmake on cygwin to maintain their settings if they need so. Regards Marco _______________________________________________ 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