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/[email protected]/msg16634.html
http://www.mail-archive.com/[email protected]/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/[email protected]/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/[email protected]/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/[email protected]/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
On 22/11/2011 08:25, Martin Sustrik wrote:
> Hi Stuart,
>
>> Andreas mentioned that cmake-generated VC projects retain some
>> dependency on cmake. I'll look into that using the build script that
>> Steve-o provided last month. In the meantime, I shall maintain this
>> patch on a separate branch.
>
> Great! Keep the list posted about the progress, problems etc.
>
> Martin
>
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
