[Bf-committers] Get Cmake on-par with scons (docs, batch files and configuration scripts)

Sun Dec 20 20:59:33 CET 2015

Ok so I start a new thread then following discussion regarding cmake 
switch. I know they are not due to cmake, it's just the cmake wiki-docs 
and scripts needs some tweeks and/or a batch file to bring it on scons 
level. At the moment, following the docs here 
http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/msvc/CMake 
we have many steps to follow, it breaks when switching branches or 
adding new functionnality unlike scons and the final build is missing 
many parts compared to official builds. Here are things that I think 
should be fixed before making the final switch.

- Have a one line command for cmake just like for scons (python 
scons\scons.py -j 4) to build  a version of blender similar in 
functionality and build parameters to the official/buildbot ones. "make 
full" like on linux seems good.
I tried Antony .bat file, but it doesn't find many libs and fails . 
Using the Cmake GUI or scons works. Error message are like those one:
--------------------------
-- Could NOT find JPEG (missing:  JPEG_LIBRARY JPEG_INCLUDE_DIR)
-- Found Freetype: 
C:/Users/test/blender_git/blender/../lib/windows_vc12/freetype/lib/freetype2ST.lib
--------------------------
- It may be due to temporary errors in the code, but in our case with a 
full GUI build (only way working for us atm), 2 modules fails to compile 
with cmake since about 1 week. Buildbots however seems to be ok?

Am 20/12/2015 um 19:57 schrieb Sergey Sharybin:
> As for the issues with default config on msvc+cmake -- i never really ad
> issues, it always working "out-of-the-box" for me and likely for other
> active developers. However, we can't _always_ guarantee latest Git is
> always compilable, it's possible to have occasional compilation errors. If
> it's something bigger for you -- please do a fuller report here in the ML
> (in a separate thread tho!). Such issues are not something which is caused
> by the build system and should be reviewed anyway and separately.
>
> As for the release-like configuration -- here are the points:
>
> - Default configuration _must_ be identical on all platforms
> - Some of the features requires 3rd party libraries
> - We can only have pre-compiled libraries for WIndows and OSX, for Linux
> one is doomed to either use library from the repository or compile himself
> (which isn't always trivial)
>
> So for the default configuration we prefer to have configuration which does
> not require some obscure libraries.
>
> On another hand, however, in GNU-like environment it's simple to do full
> build:
>
>    make full  # invoke from the sources root directory
>
> Perhaps we can have something similar on Windows? .bat script maybe?
>
> Switching branches is a weird thing. I've got both SCons and CMake failing
> at some points. This seems to be much better with latest versions of CMake
> tho. And yeah, you don't really need to force full-cmake regeneration after
> changing the branch. For the compilation you can simply invoke building
> command (msbuild or name, depending on the generator).
>
> So all in all mentioned issues seems something what we can address and not
> really caused by the building system on it's own. But that's for the
> feedback :)
>
>
>
>
> On Sun, Dec 20, 2015 at 11:22 PM, Antony Riakiotakis <kalast at gmail.com>
> wrote:
>
>> You don't need to open visual studio. You can just use nmake from
>> command line. What I personally do is have a nice batch file to do the
>> job for me. It only works from a developer command prompt for visual
>> studio. Here are its contents:
>>
>> cd c:\src\blender
>> git checkout master
>> git pull --rebase
>> git submodule update --recursive --remote
>>
>> cd c:\src\blender-build
>> del CMakeCache.txt
>> cmake ..\blender -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release
>> -DWITH_RAYOPTIMIZATION=ON -DWITH_CODEC_FFMPEG=OFF -DWITH_PLAYER=ON
>> -DWITH_IMAGE_OPENEXR=ON -DWITH_OPENCOLLADA=ON -DWITH_CYCLES=ON
>> -DWITH_OPENMP=ON -DWITH_CYCLES_CUDA_BINARIES=OFF
>> -DWITH_MOD_OCEANSIM=ON -DWITH_FFTW3=ON -DWITH_LIBMV=ON
>> -DCMAKE_VERBOSE_MAKEFILE=OFF -DWITH_CYCLES_OSL=ON
>> -DWITH_IMAGE_REDCODE=OFF -DWITH_OPENSUBDIV=ON
>> -DWITH_PYTHON_INSTALL_NUMPY=OFF
>>
>> nmake install
>>
>> On 20/12/2015, matmenu <matmenu at live.fr> wrote:
>>> Exactly what Antony said. Nobody will care what the building system is,
>>> if it works out of the box. At the moment, it works perfect on Linux,
>>> but it's still not working flawlessly on windows for me and other
>>> friends. We made a little list of things that don't work properly:
>>> - When using the cmake_full script, 2 modules fail to build in VS2013
>>> (blenderplayer-related).
>>> - "cmake_full" script is not default.
>>> - With Scons it is a one-line cmd that compiles a release-like build in
>>> one step. With cmake, following the wiki doc, we have to 1) Start the
>>> GUI and choose the folders 2) configure, change some parameters manually
>>> 3)generate solutions, 4) open VS 5) switch from debug (default) to
>>> release 6) start the building process.
>>> - Switching branches is a pain. Everytime we switch the branch, we have
>>> to 1)delete cache, 2)configure and add my cutom params manually agin
>>> (with scons, it was just added to the scons script) 3) generate solution
>>> etc... otherwise, not all files are taken into account (for example for
>>> object_nodes branch which has a lot of new files) and build fails. With
>>> scons, the git checkout was enough to have the branch-specific scons
>>> script and run the one-line again.
>>> So I agree that the best experience on Linux is with Cmake, but on
>>> Windows, it's still far away from ideal. Maybe just because I don't know
>>> Cmake on windows well and the wiki doc is not adapted, but either it's
>>> in doc or scripts or both, there is still some things to do to make it a
>>> good switch. Fixing windows specific-bugs is already not funny, so it
>>> would be good to make the build process as easy as with scons.
>>>
>>>
>>> Am 20/12/2015 um 16:37 schrieb Antony Riakiotakis:
>>>> +1 to drop scons. It may be easy to setup for casual builders, but so
>>>> is cmake, if we provide good defaults.
>>>>
>>>> On 20/12/2015, Thomas Dinges <blender at dingto.org> wrote:
>>>>> I use SCons too, but I also use CMake from time to time, so it's not a
>>>>> big deal to switch over.
>>>>>
>>>>> Therefore, I fully support removing SCons. Not sure we really need to
>>>>> wait for 2.8x to do it though, imho it's fine to drop it now, we still
>>>>> need 1-2 months before a new 2.7x release I guess, should be time
>> enough
>>>>> to communicate the change.
>>>>>
>>>>> Thomas
>>>>>
>>>>> Am 20.12.15 um 15:22 schrieb Mike Erwin:
>>>>>> I use SCons but support the idea of having only one build system.
>> Never
>>>>>> had
>>>>>> much luck building Blender with CMake but am willing to learn!
>>>>>>
>>>>>> -- Mike
>>>>>> _______________________________________________
>>>>>> Bf-committers mailing list
>>>>>> Bf-committers at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>