i think i have all the process right, it was building properly a until a few days ago, it seems that the library its there
we occasionally update them, it’s recommended to run make update on a regular basis, if it keeps giving you trouble just remove your build folder and it’ll sort it self out.
1 Like
ok ill try updating tomorrow or redo the process is still nor working.
thanks
I am getting the same error with python 3.8 and blender 2.93
CMake Error at CMakeLists.txt:911 (message):
At least Python 3.10 is required to build, but found Python 3.8
In my case, I am building blender as a module to use in a python3.8 library (I need to be able to compile for different minors of python 3).
I ran the following build command
make bpy BUILD_CMAKE_ARGS="-D PYTHON_VERSION=3.8"
Do I need to compile the dependencies manually in this case?
Couple of things, blender 2.93 shipped with python 3.9, so it asking for 3.10 seems “iffy” are you sure you are building the code you think you are building? The 2.93 tree has the version check on line 839 and checks for 3.9.
As for the version check, usually when we add a check for a minimum version, we use parts of the API that the new python version offers, so it’s quite likely the code really just won’t build against older python versions.
UPDATE: from below. All you need to do it run
svn revert --recursive .
in the lib/linux_centos7_x86_64 directory.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I had a similar problem and found it straightforward to compile python3.10 and install it in its own directory for blender to build with.
I’ve posted at python - Unable to build blender - Stack Overflow
but I’ll paste the procedure here as well.
It should take less than 10 minutes to get to compiling blender again.
My distro ( Devuan ) doesn’t yet offer python3.10. I compiled and installed it in a custom directory so as not to affect existing python installations.
Find the python version you need and download it from
https://www.python.org/downloads/
Expand it in a working directory ( ok to delete later ):
tar -xf Python-3.10.8.tgz
cd Python-3.10.8
now configure python to build with custom paths ( here I’m using ~/blenderpython )
export set BLENDERPYTHONDIR=/home/`whoami`/blenderpython
./configure --enable-optimizations --prefix=$BLENDERPYTHONDIR
make -j 4
make install
Add required packages:
cd $BLENDERPYTHONDIR/bin/;
./pip3 install numpy;
./pip3 install requests;
./pip3 install zstandard;
./pip3 install cython;
./pip3 -vvv list # to see installed and where.
# i.e. all installed in ~/blenderpython/lib/python3.10/site-packages
Now go to your blender source… in home dir?
cd ~/blender-git/blender/
and try building again specifying your new python
BUILD_CMAKE_ARGS=-DPYTHON_EXECUTABLE=$BLENDERPYTHONDIR/bin/python3.10\ -DPYTHON_LIBRARY=$BLENDERPYTHONDIR/lib/libpython3.10.a\ -DPYTHON_INCLUDE_DIR=$BLENDERPYTHONDIR/include/python3.10/ make full
note there are two backslashed spaces in the command above.
note PYTHON_EXECUTABLE and PYTHON_LIBRARY point to files. PYTHON_INCLUDE_DIR points to… a dir.
I’m a little confused what’s going on, why go through all the trouble of building 3.10.8? that is the version we are currently shipping in svn, just grabbing it from our repository would by far have been the easiest way to go about this?
I had wondered… looks like the make update lies to us ( see below).
Now I’ve manually cloned from svn the lib into a new lib2 directory and sure enough I’ve seen python3.10 updates fly by. It’s taking over an hour (not yet done… keeps halting - busy server?).
I tried again to do a “make update” in the blender directory :
The make update does claim: “Updating Precompiled Libraries and Tests”
and proceeds to do an svn cleanup and update of the linux_centos7_x86_64 lib and reports: “At revision 63081”.
I see references to the python info in revision back in revision 63074 but my lib/linux_centos7_x86_64/python is sparsely populated despite being a later revision.
It’s been another 30 min (at least) and I’ve finally got linux_centos7_x86_64 cloned into lib2 and it reports: “Updated to revision 63081.”
Renaming things so the newly cloned lib dir is in place (I’m not doing it again! ) and clearing the CMake cache results in a successful build using the centos python resources.
I’m worn down atm… but will look into a bug report later…
@LazyDodo and @JJones This is just a comment for what’s been happening recently (over the last week or so).
Quite a few people are running make update then make and experiencing some error related to Python not being found. And like JJones experienced, the python directory in the libs folder appears to be missing some files/folders:
I believe LazyDodo has talked about this earlier (on other platforms). The make update process makes use of Python at certain steps. And it doesn’t really like it if the python in the libs folder updates while the make update process is running, and this sometimes results in errors resulting in a broken libraries folder (specifically a broken Python for some people)
I believe this is what JJones is experiencing.
I believe the fix for this is to:
- Change directory to the libs folder -
cd ~/blender-git/lib/linux_centos7_x86_64 - Run svn cleanup to fix the broken libs folder -
svn cleanup - Then manually update the libraries -
svn update
Or… delete your old libs folder and download it from scratch.
I should note, I compile Blender on macOS, Linux, and Windows. And Linux was the only platform I personally experienced this issue with when the Python libs were updated over the last week or so.
yup… delete linux_centos7_x86_64 from the lib directory and then
svn checkout bf-blender - Revision 63081: /trunk/lib/linux_centos7_x86_64
is required. Doing an svn cleanup / update does NOT work… despite reporting the latest revision.
Maybe this is a bug with svn?
If the issue is the same one I think it is, then there is a way to fix it without delete your old libs folder and re-downloading from scratch. I just can’t remember the exact steps. Sorry about that.
if you still have the broken lib folder, can you run a svn diff in it? does it report anything?
svn revert --recursive . will likely recover your broken folder, but it be nice to figure out what upset it.
The svn diff reports diffs in the python directories for files that don’t exist in my tree.
The svn revert --recursive . did the trick.
I hadn’t updated/compiled blender for months so it could be a few things in that timeframe if not the timeframe itself?
I see mentions of doing a sparse checkout not allowing updates of files not initially checked out - which in this case would be the newly added python3 files since I last compiled blender? I’m speculating.
Since doing the revert I can delete the python directory and do a simple update again… and it does fetch the python files.
I’'ll keep my bad directory around to test with some more later.
It looks like this is a bug in svn that has vexed many people over the years. The following web pages include Windows, Mac and Linux users experiencing the problem.
The only consistently working solution seems to be to use revert.
revert would make sense for blender’s use here as well would it not?
I modified build_files/utils/make_update.py to use revert instead of update:
- call(svn_non_interactive + ["update", dirpath])
+ call([args.svn_command, "revert", "--non-interactive","--recursive", dirpath])
I may have jumped the gun on this… but here’s the diff for further review comments changes etc:
https://developer.blender.org/D16365
and I’ve taken the liberty of adding LazyDodo and Alaska as subscribers.
Regarding Python creating temporary files in the SVN directory.
We could run Python with PYTHONDONTWRITEBYTECODE=1 when it’s located in Blender SVN directory, or we could have the make update script remove __pycache__, although it is a bit weak to have solutions that only apply to Python.
On the other hand, if Python is the only program in our SVN that is creating temporary files - that may be an acceptable solution.
That’s what we do on windows, we start python -B which afaik does the same thing
If I run svn resolve -R and select merge it will then let me successfully do an svn update .
This is the only issue it found:
➜ linux_centos7_x86_64 svn resolve -R
Searching tree conflict details for 'python' in repository:
Checking r63074... done
Tree conflict on 'python':
A new directory appeared during switch to
'^/trunk/lib/linux_centos7_x86_64/python@63077'.
It was added by campbellbarton in r63074.
An unversioned directory was found in the working copy.
Select: (p) Postpone, (r) Mark as resolved, (m) Merge the directories,
(h) Help, (q) Quit resolution:
supposedly it can be run non-interactively using --accept=ARG so this might be something to add to the update script?
I’m a little confused on what you are trying to do? To fix the issue we currently have with the lib folder we posted several times already svn revert is the way to go here. This is hopefully a one time problem, so no scripts updates are needed to deal with this situation.
I wrote the results of my investigation into the (now abandoned) diff linked above. Python writes to the directories and SVN won’t write changes to that area… so I expect this will happen again ( and must have happened before ). I suspect most developers do as I have in the past… just wiped the directory and re-fetched. I just went down the rabbit hole this time 
I view the precompiled libs separately from the general blender development so see the update more as a directory sync. Using a different version control ( i.e. SVN instead of git) reinforces this perspective. Can community developers commit changes to svn?
I’ve written a test for svn conflicts ( there’s one for git already). Combined with a python specific solution might be appropriate ( as python would have conflicts constantly). Deleting the cache directories might not work -if I delete everything under the python directory it still refuses to retrieve files - which indicates it has some (confused) internal tracking of ‘dirty’ directories ( also based on comments I’ve come across elsewhere ).
Oh what the heck… I’ll put up the diff… but will just link here: ⚙ D16377 Check for svn collisions
UPDATE: I was wrong: python shouldn’t have conflicts normally as the cache files are properly ignored by svn.
Maybe a check for svn conflicts along the lines of the check already done for git would be appropriate, and consistent.
@LazyDodo is right… this particular case is probably a one time problem.
I’m ready to drop this… learned a bit, next!
But I made requested revisions to D16377 as it is a good check to do.