[Bf-committers] SCons build system future
sergey.vfx at gmail.com
Sun Dec 20 19:57:15 CET 2015
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
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
On Sun, Dec 20, 2015 at 11:22 PM, Antony Riakiotakis <kalast at gmail.com>
> 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
> 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
> >>> 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.
> >>>> 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
With best regards, Sergey Sharybin
More information about the Bf-committers