I've used cmake extensively, as well as autotools. cmake is gaining acceptance although autotools is far more pervasive for *nix environemnts. cmake can indeed emit MS project files for command line builds via NMAKE and/or IDE project builds. The approach I usually take is to emulate the config.h.in -> config.h autotools style of programming so that all source still retains the familiar glue:
#ifdef HAVE_CONFIG_H #include <config.h> #endif Sadly, "build wars" is a bit of a losing battle. cmake can still become unpleasant to maintain if you try to satisfy too many diverse environments. Typically upstream shops will simply bifurcate their distributions and release source tarballs based on autotools (or even just plain vanilla makefiles) for the *nix people, as well as Microsoft-friendly .msi installers for Windows runtime and software developer kits. The .msi runtime and sdk style of delivery is very appealing for many institutions. They are digitally signed and verified and easy to install. Double-click to install and you start coding immediately. Phil > having to maintain multiple sets of Windows build files is the problem > indeed. It seems like for each iteration of Visual Studio we need to > create another set of project files as the conversion doesn't seem to > work as expected (at least import library location is lost during > conversion). > > This is the reason why something like CMake as an abstraction would be > a lot more appealing. As far as I understand it's possible to generate > Visual Studio project files using CMake. If this works well nothing > would prevent us from distributing the project files separately. Does > this sound acceptable? > > I don't think we can drop MSVC9 support in the middle 2.1 cycle as > this would be a major backwards compatibility break. > > -- > Mikko Koppanen
signature.asc
Description: Digital signature
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
