Windows CMake Build

[willyd]

Hi,

This PR is not yet completely ready for merge so I am just starting a discussion here to see if there is any interest in supporting the CMake build for Windows.

TL;DR;

• Added support for building using CMake.
• Dependencies (boost, opencv, etc.) are automatically downloaded as pre-built binaries
• The project builds a DLL without adding the declspec decorations (see below for details)

Long Version

Personally, I find that when using CMake with the Ninja generator build times are often much lower than with msbuild (thanks to @LitingLin for mentionning that in #2816). Especially when CUDA files are involved. However, this could be only a CMake issue because of the way it builds CUDA enabled libraries (I don't know if msbuild can built CUDA files in parallel?). Also supporting CMake is useful for other CMake based projects that would link to caffe.

The two main issues that need to be solved to support CMake are:

• Getting the dependencies
• Handling the static registration of the caffe layers

Getting the dependencies
For the dependencies I updated my caffe dependency build tool https://github.com/willyd/caffe-builder so that it downloads, builds and installs all the required libraries in just a single command using CMake and Ninja (building all the required depedencies takes about one hour on appveyor. It also distributes the required Find*.cmake modules so that the right libraries are found all the time. To make it easier for every one I opted for an approach like the nuget approach where all the dependencies are downloaded automatically at cmake time. So any one that wants to build the caffe project just needs to do something like:

git clone https://github.com/BVLC/caffe.git
cd caffe
git checkout windows
mkdir build
cd build
call "%VS120COMNTOOLS%..\..\VC\vcvarsall.bat" amd64
cmake -GNinja -DBLAS=Open -DCMAKE_BUILD_TYPE=Release ..\
ninja

One could use other generators but the downloaded binaries only contain the release configuration currently so building the Debug configuration would fail in VS. This limitation comes from the fact that building both release and debug configs on appveyor is not possible due to build time limits. I do intend to provide binary builds for both Debug and Release configs of the required dependencies through caffe-builder releases. caffe-builder offers other options to support cmake less intrusively (via the -C command line option).

Static regsitration of the caffe layers
CMake 3.4 introduced the WINDOWS_EXPORT_ALL_SYMBOLS which makes generating shared libraries without the usual delcspec decoration possible. There are some limitations as exposed in the Kitware blog. So the CMake build currently only supports building shared libraries. Building static libraries is also possible (I did it in the past) using #pragmas to force inclusion of symbols in the consuming project.

@pavlejosipovic Please comment on the possibility of integrating these changes when ready.

cc @shelhamer I know the core caffe devs do not intend to support Windows but I thought you might want to be aware of this

[shelhamer]

@willyd migrating the Windows build to CMake seems like a good step to bring it more in sync with master and the other platforms, but I defer to @pavlejosipovic on this. Thanks for keeping up the windows dev effort!

[lukeyeager]

I agree, we should try to stick to a single build system if possible. See discussion at #3351.

[LitingLin]

It can't make in-project files build in parallel, sorry.
@willyd msbuild has a /m switch like gnu make -j.
I just found it recently. You can have a try. (Known: Can not use it on this Microsoft port's sln project file)
msbuild caffe.sln /m
or install directly (equivalent to make install)
msbuild INSTALL.vcxproj /m

[willyd]

Update:

• Added support for building static libraries. Uses a scheme similar to the one described above.
• Fixed missing solvers and layers in shared library build. This required moving the implementation of LayerRegistry and SolverRegistry to sources files.

[shelhamer]

@pavlejosipovic it seems that this and #4043 improve the build and make it a bit more standard across platforms. Could you take a look?

[recheliu]

Hi,

I tested you last commit with Visual Studio 2013 x64 as the generator, and I met an issue: When compiling common.cpp, Microsoft C/C+ optimizing compiler crashed at the following line:

dependencies\boost\include\boost-1_60\boost/type_traits/common_type.hpp(42)

The error message is useless because it is an internal error of the compiler:

1>------ Build started: Project: caffe, Configuration: Release x64 ------
1> common.cpp
1>N:\workspace\CaffeOnWindows\test_willyd\win32\vs2013\x64\cpu\dependencies\boost\include\boost-1_60\boost/type_traits/common_type.hpp(42): fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'msc1.cpp', line 1325)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

The line that caused this issue is:

template<class T1, class T2, class... T> using common_type_fold = common_type_t<common_type_t<T1, T2>, T...>;

[recheliu]

Meanwhile, can the automatically-downloaded dependencies work for later Visual Studio? If not, should we add an option to allow the manual specification of the dependencies?

[willyd]

I tested you last commit with Visual Studio 2013 x64 as the generator, and I met an issue: When compiling common.cpp, Microsoft C/C+ optimizing compiler crashed at the following line:

dependencies\boost\include\boost-1_60\boost/type_traits/common_type.hpp(42)

@recheliu Hum, weird. Ninja and VS generators are using the same compiler in the end. I'll give the VS generator a try and report the results.

Meanwhile, can the automatically-downloaded dependencies work for later Visual Studio?

They should work though I did not test it. But the package currently only contains Release libs for the reasons mentioned above.

If not, should we add an option to allow the manual specification of the dependencies?

You can actually provide your own copy of the dependencies built with the project I created to make the process of building caffe dependencies smoother. You need to specify the CAFFE_DEPENDENCIES_DIR with a CMake cache variable or Environment variable.

If you want to be able to use your own dependencies built without caffe-builder you will need to modify all the Find.cmake files in the cmake folder so that they can find the libraries correctly on windows. I think you made those changes in your fork so just cherry pick 'em and you should be able to use your dependencies.

[willyd]

@recheliu It seems that your issue with boost is known. See: https://svn.boost.org/trac/boost/ticket/11885. I use VS 2013 Update 5. What's your version?

[recheliu]

@willyd I am using Visual Studio 2013, but I cannot find out which update it is.

It is not difficult to fix. I only need to define BOOST_NO_CXX11_TEMPLATE_ALIASES. I plan to close my PR for windows patch and cherry pick mine into this one.

@pavlejosipovic Do you have any other concerns?

[willyd]

@recheliu You can find the update version in Help > About Microsoft Visual Studio. It should be at the top under MS VS Professional 2013.

[recheliu]

@willyd On my desktop, the dialog of About Microsoft Studio only says

Microsoft Visual Studio Professional 2013
Version 12.0.21005.1 REL

No other information about the updates.

[willyd]

On my system:

Microsoft Visual Studio Professional 2013
Version 12.0.40629.00 Update 5

Maybe you did not apply any of the updates.

I could add the BOOST_NO_CXX11_TEMPLATE_ALIASES define when CMAKE_CXX_COMPILER_VERSION is lower than 12.0.40629.00 in the pre-built dependencies to support this use case.

[recheliu]

@willyd
Probably you don't need to recompile your boost with BOOST_NO_CXX11_TEMPLATE_ALIASES. In my test, defining this flags in Caffe is sufficient. Maybe this flag is only needed with MSVC and Boost version >= 60.

Just closed my PR. Will start to cherry pick my changes to your fork.

[shelhamer]

@willyd would you be interested in picking up development of the windows branch? We're currently seeking a maintainer, and I know that you have been working on the caffe-builder project while also sending PRs to BVLC/caffe:windows. Let us know.

[willyd]

Hi @shelhamer,

I definitely have interest in building and in maintaining a CMake based build of caffe for Windows. However, this is already taking me a lot of time and given the number of issues that the Windows branch has received I fear that I might not be able to keep up. This is a lot of work for a man alone.

You already mentioned that BVLC has no interest and/or experience in maintaining a windows branch has this changed? What would you exactly expect from a maintainer of the windows branch? Or would anyone else be willing to contribute to this development?

Do you see this branch being merged in master in the near future?

Would that imply supporting the already existing Visual Studio .sln build or could we only support the CMake based build? I believe that most people prefer a single build system over three as mentioned by @lukeyeager but maybe the Windows community prefers to have a Visual Studio based build.

The windows branch has been lagging behind master a little bit lately. Are you aware of any way the windows branch could receive the changes added by master automatically and validate using CI? I guess the appveyor build could track the windows and the master branch and merge the windows branch into master before building master? So that merge conflicts and build issues are caught as soon as possible.

[lunzueta]

Hi @shelhamer and @willyd. I would also like to help in the maintenance of this branch. I've followed the different attempts of getting Caffe working in Windows, and I especially like the CMake-based build made by @willyd, because it allows linking externally to other projects in a simpler way than other alternatives. In the end, from my point of view (as a user) it would be great if there would be a single way of building Caffe for different platforms, in a similar way to other projects, like OpenCV.

[recheliu]

Hi,

I would also like to help.

I think that once the windows-cmake branch of willyd's fork become stable, we can either create a new branch called windows-cmake or just merge it to windows. The cmake files will not impact the existing .sln files.

Actually in my earlier tests, merging windows-cmake to master should be fine as well. The only issue is that the Windows users need to build the prerequisites by themselves, but at least it will not impact the users of Linux and Mac OS.

[willyd]

With the help of these gentlemen I would be willing to maintain the windows branch provided we use a CMake based build.

[shelhamer]

@willyd @lunzueta @recheliu thanks all for your enthusiasm and Windows dev expertise. I'm happy to delegate the branch to @willyd who can in turn coordinate with @lunzueta and @recheliu. @willyd could you share your email address?

BVLC has no interest and/or experience in maintaining a windows branch has this changed?
What would you exactly expect from a maintainer of the windows branch?

There is still no BVLC maintainer, but we welcome a community maintainer for this branch.
Any help makes a difference. If you make use of the windows branch in your own work, then that would be ideal since you would know how well it is working and what current issues there are.

It's completely fine that you do so on a best effort basis. We don't expect you to spend all of your time on it. It's good to see that there are others who'd like to share the work too.

Do you see this branch being merged in master in the near future?

Merge totally depends on the state of the branch, means to set up continuous integration, and how intrusive the code is on core Caffe.

Would that imply supporting the already existing Visual Studio .sln build or could we only support the CMake based build?

Completely up to you as the branch maintainer. Focusing on CMake to have more commonality with master makes sense, and you're welcome to take this direction in the windows branch. If the Visual Studio build turns out to be a requirement for much of the Windows community, it might have to be community maintained in its own fork.

The windows branch has been lagging behind master a little bit lately. Are you aware of any way the windows branch could receive the changes added by master automatically and validate using CI?

This should be possible through git hooks or github services, but I don't know the details for this particular use case. You might have to handle it manually, or through CI at your fork to start, but if you figure out a way to automate it we could consider how to enable this for BVLC/caffe.

Thanks all!

[shelhamer]

@willyd you're now part of the caffe-collab team on github, giving you push rights to the windows branch and control over PRs and issues. Note that you actually have push rights to all branches, given the granularity of github permissions, but please take care not to push/merge/otherwise modify the other branches. Welcome!

[willyd]

Thanks @shelhamer. With the help of @lunzueta and @recheliu I will:

• Stabilize the CMake build in my own fork
• Clean up its history and merge it in windows branch

This will include updated documentation on how to build caffe using CMake. CI is already working as can be seen from my appeyvor account. This is currently using my account, how about creating a dedicated account for the caffe project?

[shelhamer]

It's good to see progress on the windows branch @willyd, thanks for taking this on!