Is it possible? I am trying to familiarize myself with blenders build system and as practice I’m trying to git bisect a crash which didn’t happen in 2.83 and does in 2.90 (T80996).
However, I can’t get the old versions to build. I think because the lib/linux_centos7_x86_64/ dir has been updated specifically for the new version?
(I’m on linux, ubuntu focal)
Is there an easy way to get the correct lib dir from svn? make update always gets the latest version only.
Is there an easy way to get the correct lib dir from svn? make update always gets the latest version only.
While bisecting is active, you shouldn’t be running make update. This sentence sounds like you’re doing so, but I could be misunderstanding.
You can use the dates at https://download.blender.org/release/Blender2.83/ and svn commit history to find which set of libraries was used to build a particular version.
Also, creating separate parent directories like the following where lib folder is at different svn versions may be better instead of tediously running svn cleanup and rebuilds.
parent1:
- blender
- lib
parent2
- blender
- lib
No, I understand that 
I was hoping there was a similar command to make update which would pull the correct libs from svn for the current git HEAD. (Far fetched , I know, but the clarity of the blender build/development process is amazing. I’m prepared to believe in any magic here 
)
But that wouldn’t really play nice with git bisect I guess?
I think I’ll have to create multiple (versioned) lib dirs and manually switch them around when bisecting…
I’ll read those other threads.
Thanks for the reply.
Unfortunately there simply is no automatic solution to this at the moment, you have to manually switch the libs to the right version while bisecting.
This is something we want to fix at some point.
Ok, thanks for all then info.
I bashed together a quick script to automate stuff.
First I used git-svn to get a local git repository of all the precompiled libs to prevent hammering the svn server each time I switch libs.
git svn clone --prefix=svn/ -r62361:HEAD https://svn.blender.org/svnroot/bf-blender/trunk/lib/linux_centos7_x86_64/
Checks out everything you need to go back to v2.82, which is not too much.
I stored this git repo in a subdir called gitsvnlib
I the created a script to fish out the date of the currently checkout out revision in the blender subdir and check out the corresponding libs in the gitsvnlib subdir. I then symlink gitsvnlib to lib. This is not really needed but my finger memory got so used to deleting the lib subdir all the time that I do it this way to prevent accidentally wiping my painfully downloaded git repo.
script:
#!/bin/sh
cd `dirname $0`
cd blender
date=`git log -n 1 --date=iso | grep Date `
date=${date##Date:}
cd ../gitsvnlib/linux_centos7_x86_64
rev=$(git rev-list -1 --until="$date" master)
echo Checking out libraries for $date : $rev
git checkout $rev 2> /dev/null
git clean -f -d -x
git reset --hard
cd ../../lib
rm -rf linux_centos7_x86_64
ln -s ../gitsvnlib/linux_centos7_x86_64 .
this together wit another script in the blender dir named ‘t’:
#!/bin/sh
../checkoutcorrespondinglibs.sh
rm -rf ../build_linux_debug
make debug ninja
cd ../build_linux_debug/
make -j10
bin/blender
cd ../blender
make bisecting a loop of
while true:
./t
<test>
git bisect <good|bad>
So far it seems to work in checking out the correct libs. But I still can’t build v2.83.6.1 because I still get a compilation error. Maybe some off-by one error in which lib version I need.
btw. It’s extremely helpful to set up ccache and add
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
to the top of CMakeLists.txt when doing this. (which you then need to git stash and git apply for each bisect, now that I think of that I should stick that into the ‘t’ script as well…)
edit:
it doesn’t work for 2.83.6.1 (I get some compilation error) but it does seem to work for most later revisions, so I can bisect. I’ll try to find out why 2.83.6.1 doesn’t want to build maybe later
Wouldn’t it be a good idea to add a ‘ccache’ target to the GNUMakefile to add the
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
line to the CMake input. Analogous to how the developer options and the like are added?
Especially when bisecting over a large range like I now did a few times you need to wipe/clean the build directory between bisect steps to reliably build each version. Especially in that case ccache cuts the build times in a huge way.
I now have that extra line git-stashed away and I add it before each bisect step and remove it afterwards, but it would be nice to be able to just run ‘make debug ninja ccache’ .
I can add it to the GNUMakefile if people think it’s a good idea.
I have some common cmake config options as environment variables (~/.bash_profile) and I pass them to cmake without touching the source code as follows
export NINCCACHE="-G Ninja -DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_CXX_COMPILER_LAUNCHER=ccache"
cd build_folder
cmake $(NINCCACHE) ../blender -C <path to the blender_*.cmake config files> -D<other option>=<value>
https://wiki.blender.org/wiki/Building_Blender/Options#Setup_For_Developers
We have it as an option for make on windows, adding it as a convenience option on linux wouldn’t be the worst thing i guess (then again, not my platform, so it’s not like my opinion carries any weight there)
That works as well. Still slightly ,more cumbersome than having it in the GNUMakefile imho.