I want to prepare the development environment with Blender + python. Blender's built-in editor and console are difficult to use, so I want to use it from vscode I want to develop and debug my own add-on and easily check the behavior of the bpy function.
You can't ʻimport bpy` by hitting blender's python directly. You need to run python via blender.
How can I run blender from command line or a python script without opening a GUI? https://blender.stackexchange.com/questions/1365/how-can-i-run-blender-from-command-line-or-a-python-script-without-opening-a-gui
$ blender --background --python-console
Will bring up the python console.
It seems that this area can be used.
High-speed data transfer with Blender's C ++ add-on (LuxBlend method) https://qiita.com/vipper36/items/3e6012c3c770ade0d412
[Blender] Automate Blender add-on testing with GitHub and Travis CI https://qiita.com/nutti/items/fe3f3f14168155df5916
If you want to do the above blender as module or something special, it will be quick to build from the source code.
After dropping the source code and the prebuilt binary of the dependent library, You can build it just by doing basic make. Don't forget to do git submodule. If I do not
file INSTALL cannot find "/home/mdriftmeyer/DeveloperProjects/Blender-Repository/blender/release/datafiles/locale/languages".
I get an error around the locale.
Building Blender itself doesn't take much time as there is a prebuilt binary on Ubuntu. It took about 5 minutes with Threadripper 1950X.
$ make headless
You can build without GUI.
Blender as module
There is a build that makes Blender itself a python module (
With this, you can ʻimport bpy` with your favorite python interpreter etc., so it is expected that development will progress, but Ubuntu has a high hurdle.
The build command itself is simple.
$ make bpy
(It calls cmake internally, so it's a good idea to take a look at its cmake settings.)
First, bpy.so is linked with shared lib, but prebuilt libs has only
.a. It seems to be relocatable, but the library of the system on which
.a depends is also linked with .a. So I get an error when linking (eg libpng.a), libpng.a or gomp.a (OpenMP).
If libpng.a is entered with apt, it will go to
/usr/lib/.., so once you delete it with apt, link it with libpng.a on the prebult libs side. You can solve it.
However, libpng.a may not be erased in some cases, so it may be safe to build
bpy.so around Docker.
gomp (OpenMP) depends on the environment. If you have an environment such as CUDA, there is a high possibility that gomp will be installed related to gcc, and libgomp.a in
/ usr / lib / ... You will get a build fail trying to link.
This is difficult because if you remove gomp you also have to remove the gcc compiler package. After all it may be good to build with Docker.
Also, if you do not build with
WITH_MEM_JEMALLOC turned off,
cannot allocate memory in static TLS block
Error appears when importing.
Looking at the CMake settings, it should be OFF for Linux, but for some reason it is not reflected.
$ make deps
You can build the dependent libraries from source with.
With bashrc etc,
alias make=`make -j8`
If you try to build in parallel as such, compilation will fail, so it may be better to make sure that alias is not set in make before doing
make deps, but in that case 1 It takes a long time to build because it only builds on the core. It may be a good idea to build in parallel in anticipation of compiling several times.
If you build the dependent libraries from scratch, yasm (why do you need an assembler ?! I use it in the video codec system), it conflicts with the system boost, and building LLVM from scratch is troublesome.
At least OpenVDB didn't build well around boost for some reason. If you don't use VDB, why not build off for now?
bpy.so is successfully created and import does not crash, this time I get an error if there is no such thing as ʻio_xxx`. These will be add_on, so adding add_on should solve it. (add_on related is managed by another git repo)