On 07/25/2013 08:01 PM, Greg Troxel wrote:
Charles Karney <charles.kar...@sri.com> writes:
On 06/29/2013 09:05 PM, Mateusz Loskot wrote:
I don't know what's typical, regarding developer's reaction on CMake adoption
proposal, but as a big fan of CMake, I wouldn't paint it in pink colours only.
Thus, I understand, for example, Frank's experience may be very different.
Finally, if a software has a build system that is usable and works on
all supported
platforms, I also understand a team may go for lean approach: don't change it.
I basically agree. However, let's not forget those users who need, for
one reason or another, to compile these packages themselves.
I find it odd to talk about how one can't compile packages oneself when
they use autoconf.
Is this really about accommodating windows without using cygwin? I have
found that autoconf/automake/libtool is really quite workable.
Windows support is the important issue for some users. CMakes's other
big advantage relative to autoconf is that it provides a more systematic
way of discovering dependent packages.
I agree that, as a user of a package, autoconf on non-Windows systems
works well. However, for the developer of a package, autoconf seems
like an ugly hacked-together mess, which I would not recommend to anyone
starting on a new package. Nevertheless, I concede that the issue gets
more complicated for large packages which already have autoconf support.
Does cmake support
building in an objdir, with a read-only srcdir
cross-compiling
the equivalent of 'make dist' and 'make distcheck'
building on a system not previously known to the build system, as
long as feature tests are doable
The answer to these is yes. In particular, building outside the source
tree is the standard procedure with cmake.
_______________________________________________
osgeo4w-dev mailing list
osgeo4w-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/osgeo4w-dev
