Hi Stuart, Let me summarise.
The problem we are solving is that MSVC2008 project doesn't convert seamlessly into MSVC2010 project (some directory setting is broken in the provess IIRC). The solution so far seems to be to discard the MSVC build system, replace it by CMake build system, then bundle CMake with libzmq and make the whole bunch work together. My question thus is: Isn't there an easier way to solve the problem? Like, say, abandoning MSVC2008 and requiring MSVC2010 to build libzmq? Martin On 11/23/2011 02:27 AM, Stuart Webster wrote: > There's good news and bad news. > > First, the good news is that the implicit dependency that Andreas > mentioned can be avoided by specifying "set(CMAKE_SUPPRESS_REGENERATION > 1)" in CMakeLists.txt. The default behaviour is for cmake to add a > pre-build step that will regenerate Visual Studio projects if it detects > any changes in the CMakeFiles subdirectory of their build folder, but I > verified that this step was absent from the libzmq project generated > from Steve-o's CMakeList.txt after adding this flag. > > The bad news is that this deployment model isn't officially supported by > the cmake developers, who caution against doing this. They actually > recommend bundling cmake with your CMakeList.txt file(s) instead: > http://www.mail-archive.com/cmake@cmake.org/msg16634.html > http://www.mail-archive.com/cmake@cmake.org/msg12692.html > > Cross-generating MSVC project files from other operating systems is not > possible, so you would need to generate them on a Windows build machine: > http://www.mail-archive.com/cmake@cmake.org/msg12736.html > > One thing to be aware of is that the current release (2.8.6) has a bug > in which it always specifies absolute paths of source files in generated > MSVC project files, even if you specify relative paths > ("set(CMAKE_USE_RELATIVE_PATHS 1)") in your make file. That means that > we would be restricted to using an unsupported older release: > http://www.mail-archive.com/cmake@cmake.org/msg39143.html > > Lastly, generating projects that target both 32- and 64-bit platforms is > not possible either, so you would have to generate a separate project / > solution for 64-bit builds: > http://www.mail-archive.com/cmake@cmake.org/msg38787.html > > I was planning to extend the project in my original patch to support the > Intel compiler as well (it can use the unpatched C99 openpgm code and > generates faster binaries, but that's a topic for another day). It would > be unfeasible to provide that support if it meant doubling the number of > solutions shipped with the source code, but it looks like it would be > easy enough to add to the CMakeLists.txt file. > > In summary, it is possible to use cmake to generate MSVC project files > that have no dependencies on cmake itself. However, that's not what it > is designed to do, we would have to use an old version to do so on a > Windows build machine and the generated project (I presume there would > be only one) would only support 32-bit build targets. Couple that with > the fact that providing generated project files firmly places the > responsibility for those files with the zeromq community and I can see > why the cmake guys recommend just bundling cmake with your project. > > If we went down that road we would need to make sure that we bundle a > version of cmake that does not suffer from the relative path bug. I > think Martin was correct the other day when he suggested that the > typical use case at most Windows shops will be for the guy who > downloaded 0MQ to build the library on his workstation and then import > the source into the relevant corporate repository. If the project files > that he generated contained absolute paths, the next person to try to > build 0MQ will likely get a bunch of errors, which creates a very poor > first impression. > > Stuart _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
