Did you compile and install all of Blender dependencies or you just ran this command after getting the code from github?
If your having trouble you can use the file located here: cd [blender git location] ./blender/build_files/build_environment/install_deps.sh that will do a lot of the heavy lifting for you. If you want to manually build and install the dependencies. You can use this command cd [blender git location] ./blender/build_files/build_environment/install_deps.sh --show-deps to get a print out of all the dependencies then manually install those to a sane location. Once you install those dependencies if you then have to point CMAKE to where you installed those so that it can find them. I had some trouble with the install_deps.sh file but after a while it all built successfully. I personally like the cmake approach better but if Blender requires external libraries I think it would be worth looking into setting up blender as an external_project structure since that would allow you to download anything and do really advanced builds: https://cmake.org/cmake/help/v3.0/module/ExternalProject.html The problem with that is that external projects and add_subdirectory don't play nicely with each other and require a lot of hacks..... to get them working together. On Mon, Dec 21, 2015 at 3:30 PM, matmenu <matm...@live.fr> wrote: > As Sergey, Antony and you all agreed on making a batch file, would it be > possible to put it in the official git? It would maybe resolve some of > the issues that are specific to the GUI workflow? For the exact error > message, I'll post them tonight as soon as I'm back home. > Here is the version from Antony modified to have all the feature set of > the full cmake version: > > ------------------------------------------------ > > cd %HOMEPATH%\blender_git\blender > git checkout master > git pull --rebase > git submodule update --recursive --remote > > cd %HOMEPATH%\blender_git\blender-build > del CMakeCache.txt > cmake ..\blender -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release > -DWITH_BUILDINFO=ON -DWITH_BULLET=ON -DWITH_CODEC_AVI=ON > -DWITH_CODEC_FFMPEG=ON -DWITH_CODEC_SNDFILE=ON -DWITH_CYCLES=ON > -DWITH_CYCLES_OSL=ON -DWITH_FFTW3=ON -DWITH_LIBMV=ON > -DWITH_LIBMV_SCHUR_SPECIALIZATIONS=ON -DWITH_GAMEENGINE=ON > -DWITH_COMPOSITOR=ON -DWITH_FREESTYLE=ON -DWITH_GHOST_XDND=ON > -DWITH_IK_SOLVER=ON -DWITH_IK_ITASC=ON -DWITH_IMAGE_CINEON=ON > -DWITH_IMAGE_DDS=ON -DWITH_IMAGE_FRAMESERVER=ON -DWITH_IMAGE_HDR=ON > -DWITH_IMAGE_OPENEXR=ON -DWITH_IMAGE_OPENJPEG=ON -DWITH_IMAGE_REDCODE=ON > -DWITH_IMAGE_TIFF=ON -DWITH_INPUT_NDOF=ON -DWITH_INTERNATIONAL=ON > -DWITH_JACK=ON -DWITH_LZMA=ON -DWITH_LZO=ON -DWITH_MOD_BOOLEAN=ON > -DWITH_MOD_FLUID=ON -DWITH_MOD_REMESH=ON -DWITH_MOD_SMOKE=ON > -DWITH_MOD_OCEANSIM=ON -DWITH_AUDASPACE=ON -DWITH_OPENAL=ON > -DWITH_OPENCOLLADA=ON -DWITH_OPENCOLORIO=ON -DWITH_OPENMP=ON > -DWITH_PYTHON_INSTALL=ON -DWITH_RAYOPTIMIZATION=ON -DWITH_SDL=ON > -DWITH_X11_XINPUT=ON -DWITH_X11_XF86VMODE=ON -DWITH_PLAYER=ON > -DWITH_MEM_JEMALLOC=ON > > nmake install > ------------------------------------------------ > Note that on my computer, this batch file fails to find most librairies > and I have no idea why. > > > Am 21/12/2015 um 01:50 schrieb Campbell Barton: > > Some of the issues you've described seems quite strange and I've never > > encountered on MS-Windows+MSVC. > > > > On Mon, Dec 21, 2015 at 5:08 AM, matmenu <matm...@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). > > What fails? can you link to build error? > > > >> - "cmake_full" script is not default. > > This is also the case with CMake on Linux/OSX, > > though the reasoning for this on Linux is that linking errors with > > FFMPEG/Collada/LLVM are more common - and the libraries are not > > essential in many cases. > > > >> - 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. > > On Unix systems we have a convenience makefile that handles this > > ('make' in the source dir to configure+build+install). > > We could have a BAT file for Windows to do the equivalent steps. > > > >> - 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. > > I've never heard of switching branches needing to delete cache, > > What custom params are you having to set each time? > > > >> 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. > > With the issues you run into, its best if we can try to redo and fix > them. > > > >> 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 <blen...@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@blender.org > >>>>> http://lists.blender.org/mailman/listinfo/bf-committers > >>>> _______________________________________________ > >>>> Bf-committers mailing list > >>>> Bf-committers@blender.org > >>>> http://lists.blender.org/mailman/listinfo/bf-committers > >>>> > >>> _______________________________________________ > >>> Bf-committers mailing list > >>> Bf-committers@blender.org > >>> http://lists.blender.org/mailman/listinfo/bf-committers > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers