https://wiki.luxcorerender.org/api.php?action=feedcontributions&feedformat=atom&user=HowetuftLuxCoreRender Wiki - User contributions [en]2026-04-30T20:25:34ZUser contributionsMediaWiki 1.43.5https://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2703Building LuxCoreRender - FAQ2026-04-28T03:22:34Z<p>Howetuft: </p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
Then you will build the deps with [[Building_LuxCoreRender#Local_Plain_Build|local plain build]].<br />
<br />
After having built dependencies in local, you may want to inject them in LuxCore build. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)<br />
<br />
At this stage, you will be able to build LuxCore artifacts, embedding the debug information of dependencies, for instance:<br />
<pre><br />
export LUX_BUILD_TYPE=Debug<br />
make wheel-test # If the previous steps have been completed, the testing wheel will contain deps' debug info<br />
</pre><br />
<br />
Remark: in this scenario, do not build the dependencies with CI local build, as the deps source files should be inaccessible at the end of the build, what should make the deps debug info useless.<br />
<br />
== How can I build a sanitized version of LuxCore? ==<br />
<br />
It is possible to build a sanitized version of LuxCore, including <code>luxcoreui</code>, <code>luxcoreconsole</code>, <code>pyluxcore</code> and the wheels.<br />
It just consists in setting the environment variable <code>LUX_SANITIZE</code> before the build:<br />
<br />
<pre>export LUX_SANITIZE=1 # or whatever value you want</pre><br />
<br />
To come back to unsanitized build, just <code>unset LUX_SANITIZE</code>.<br />
<br />
2 caveats:<br />
* You'll need to export the following before running LuxCore:<br />
<pre>ASAN_OPTIONS=protect_shadow_gap=0</pre><br />
otherwise LuxCore will stop early with the following error message:<br />
<pre>terminate called after throwing an instance of 'std::runtime_error'<br />
what(): CUDA driver API error CUDA_ERROR_NOT_INITIALIZED<br />
</pre><br />
* Unfortunately, sanitized version of the wheel will not do with Blender, as Blender has special code to control sanitizing and will override ours.<br />
<br />
== In Linux, I try to set an environment variable that should control LuxCore build, but it does not work ==<br />
<br />
In Linux, for LuxCore build system to take them into account, the environment variables that control the build (LUX_BUILD_TYPE, LUX_SANITIZE...) should not only be set, but also exported:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug # `set LUX_BUILD_TYPE=Debug` would be insufficient</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender&diff=2702Building LuxCoreRender2026-04-28T03:10:49Z<p>Howetuft: /* Caveats */</p>
<hr />
<div>This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.<br />
<br />
LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all [[Building_LuxCoreRender_(legacy)|previous documents]] related to the compilation of older versions (<=2.9).<br />
<br />
<br />
<b>TL;DR</b> If you are just interested in a quick, local (but platform limited) compilation of LuxCore C++ samples or Python wheels, you may want to jump directly to [[#Build LuxCore, Samples & Python Wheels | Build LuxCore, Samples & Python Wheels]].</br><br />
<br />
<br />
<br />
= Audience =<br />
<br />
This document is intended for:<br />
* LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;<br />
* Developers wishing to contribute to the project;<br />
* External package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;<br />
<br />
This document assumes that the reader is skilled in the following areas:<br />
* C/C++ compilation<br />
* [https://cmake.org/ cmake]<br />
* [https://git-scm.com/ git]<br />
* [https://docs.github.com/en/actions/writing-workflows Github Workflows]<br />
* [https://packaging.python.org/en/latest/ Python Packaging], including [https://realpython.com/python-wheels/ Python Wheels format]<br />
<br />
Familiarity with [https://conan.io/ Conan] dependency manager may also help.<br />
<br />
</br><br />
This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries on the official [https://luxcorerender.org/download/ Download] page.<br />
<br />
= Build Targets =<br />
<br />
== Synoptic ==<br />
LuxCoreRender contains several build targets, below represented with dependency links:<br />
<br />
{{#mermaid:<br />
%%{<br />
init: {<br />
"theme": "forest",<br />
"logLevel": "info",<br />
"flowchart": {"curve": "basis"}<br />
}<br />
}%%<br />
<br />
flowchart LR;<br />
<br />
<br />
classDef TYPE font-weight:bold,font-size:1.1rem;<br />
classDef TARGET font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCOREDEPS fill:#ffe8ff,stroke:#9488af,font-weight:bold,font-size:1.1rem;<br />
classDef TARGETDEPS fill:#e4d8ff,stroke:#9488af,font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCORE fill:#bbceff,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETLUXCORE fill:#7799ee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef SAMPLES fill:#ffffdd,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETSAMPLES fill:#eeeecc,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef NEUTRAL fill:#fafafa,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETNEUTRAL fill:#eeeeee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef EXTDEP fill:#00000000,stroke:#00000000;<br />
<br />
<br />
subgraph Dependencies[External Dependencies]<br />
deps(LuxCore Dependencies)<br />
end<br />
<br />
class Dependencies LUXCOREDEPS;<br />
class deps TARGETDEPS;<br />
<br />
<br />
subgraph LuxCore<br />
lux(luxcore.so/.dll)<br />
luxa(luxcore.a)<br />
end<br />
class LuxCore LUXCORE;<br />
class lux TARGETLUXCORE;<br />
class luxa TARGETLUXCORE;<br />
<br />
subgraph Python_Wheels[Python Wheels]<br />
pylux(pyluxcore.so/.dll)<br />
wheels(LuxCore Python Wheels)<br />
end<br />
class Python_Wheels TYPE;<br />
class pylux TARGET;<br />
class wheels TARGET;<br />
<br />
subgraph Samples<br />
luxcoreui(luxcoreui)<br />
luxcoreconsole(luxcoreconsole)<br />
end<br />
class Samples SAMPLES;<br />
class luxcoreui TARGETSAMPLES;<br />
class luxcoreconsole TARGETSAMPLES;<br />
<br />
<br />
subgraph PyLuxCoreTools<br />
pyluxcon(pyluxcoreconsole)<br />
pyluxothers(...)<br />
end<br />
class PyLuxCoreTools NEUTRAL;<br />
class pyluxcon TARGETNEUTRAL;<br />
class pyluxothers TARGETNEUTRAL;<br />
<br />
subgraph Plugins[Python Plugins]<br />
blc(BlendLuxCore)<br />
otherplugins(...)<br />
end<br />
class blc TARGETNEUTRAL;<br />
class otherplugins TARGETNEUTRAL;<br />
<br />
class Plugins NEUTRAL;<br />
<br />
%% Warning: order matters<br />
deps-->lux<br />
deps-->luxa<br />
deps-->luxcoreui<br />
deps-->luxcoreconsole<br />
<br />
luxa--->pylux<br />
lux-->luxcoreui<br />
lux-->luxcoreconsole<br />
deps-->pylux<br />
<br />
<br />
<br />
pylux-->wheels<br />
wheels-. runtime .->blc<br />
wheels-. runtime .->otherplugins<br />
<br />
wheels-. runtime .->pyluxcon<br />
wheels-. runtime .->pyluxothers<br />
<br />
Python:::EXTDEP-->pylux<br />
<br />
<br />
%% Mermaid version: 8.14.0<br />
%% https://github.com/mermaid-js/mermaid/blob/8.14.0/src/defaultConfig.js<br />
<br />
<br />
<br />
}}<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! Target !! Source Repository !! Content<br />
|-<br />
| <b>External Dependencies</b>|| [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreDeps</code>] || A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to [https://github.com/LuxCoreRender/LuxCoreDeps/blob/main/README.md LuxCoreDeps README] for more information.<br />
|-<br />
| <b>LuxCore</b> || [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.<br />
|-<br />
| <b>Samples</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Sample C++ programs, illustrating luxcore use, namely <code>luxcoreconsole</code> and <code>luxcoreui</code><br />
|-<br />
| <b>Python Wheels</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version).</br> As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).<br />
|-<br />
| <b>Python Plugins</b>|| [https://github.com/LuxCoreRender/BlendLuxCore <code>BlendLuxCore</code>] etc. || Plugins to expose LuxCore in various external applications, notably Blender. </br> Written in Python and relying on Python Wheels as runtime dependency.<br />
|-<br />
| <b>PyLuxCoreTools</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python LuxCore Tools: set of command line tools based on pyluxcore, written in Python.<br />
|}<br />
<br />
== Targeted platforms ==<br />
<br />
LuxCoreRender aims at being available on the following 4 platforms:<br />
* Linux (glibc 2.28+)<br />
* Windows<br />
* MacOS Intel (>=10.15)<br />
* MacOS Arm (>=12.0)<br />
<br />
For Python-related targets, LuxCoreRender aims at being declined for [https://devguide.python.org/versions all Python versions supported at a given time].<br />
<br />
= Workflow Types =<br />
<br />
We distinguish between two types of build workflows:<br />
* Developer workflows<br />
* Publisher workflows<br />
<br />
<br />
''[[#Developer Workflows | Developer workflows]]'' are designed for development, debugging and test steps.<br />
<br />
Their purpose is to allow development and verify the code is ready for publication.<br />
<br />
<br />
''[[#Publisher Workflows | Publisher workflows]]'' are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.<br />
<br />
They exclusively take place in a CI/CD Github pipeline.<br />
<br />
These workflows are not designed for debugging or testing the underlying code. Execution of these workflows assumes that the development phase has been correctly completed and the underlying code is ready for final build and release. See [[#Developer Workflows | Developer Workflows]] to learn how to get code ready for final build.<br />
<br />
Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.<br />
<br />
= Developer Workflows =<br />
<br />
<br />
== Prerequisites ==<br />
<br />
<u>Tools</u><br />
<br />
You will need several build tools installed and referenced in the PATH.<br />
<br />
First, ensure you have a suitable toolchain:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! OS !! Compiler !! Minimal version<br />
|-<br />
| Windows || MSVC || 194x latest version<br />
|-<br />
| Linux|| gcc || 14<br />
|-<br />
| MacOS Intel|| XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|-<br />
| MacOS Arm || XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|}<br />
<br />
''Toolchain compliance is a very sensitive condition for a successful build. Before filing any claim, please check that your toolchain complies with the above requirements.''<br />
<br />
<br />
<br />
Then ensure the following software is also installed and available in your PATH:<br />
<br />
* [https://git-scm.com/ Git]<br />
* [https://cli.github.com/ Github CLI] (optional but recommended - for dependency signature checking)<br />
* [https://www.python.org/ Python 3] - any [https://devguide.python.org/versions/ currently supported version]<br />
* [https://conan.io Conan] latest version (pip install conan)<br />
* [https://github.com/pypa/wheel/tree/main Wheel] latest version (pip install wheel)<br />
* [https://cmake.org/ CMake] >= 3.29<br />
* [https://github.com/nektos/act nektos/act] (optional but recommended - for local build based on Github workflows)<br />
* [https://pypi.org/project/repairwheel repairwheel] (optional but recommended - for local build of test wheels)<br />
<br />
<br />
Platform specifics:<br />
* For Windows, ensure the command line is configured for building (<code>vcvarsall.bat</code>).<br />
* For Linux, you'll need <code>pkgconfig</code> in addition.<br />
* For MacOS, you'll need to ensure CC and CXX point to LLVM clang/clang++<br />
<br />
<u>Accounts</u><br />
<br />
A ''Github account'' is mandatory for LuxCore development.<br />
<br />
Following accounts are also recommended, in order to get in touch with LuxCore community:<br />
* [https://forums.luxcorerender.org/ LuxCoreRender Forums]<br />
* [https://discord.gg/chPGsKV LuxCoreRender Discord channel]<br />
<br />
== General Developer Workflow ==<br />
<br />
To compile and verify LuxCore component modifications in development process, there are 3 stages:<br />
* Local plain build: only run build system (cmake) on developer computer<br />
* Local Continuous Integration build: run full Continuous Integration workflow on developer computer<br />
* Server Continuous Integration build: run full Continuous Integration workflow on server<br />
<br />
<i>Local plain build</i> is generally faster than other builds and does not require to commit changes beforehand. Plain build installs a minimal build configuration (dependencies), but heavily relies on computer build environment for the rest (build tools, system libraries etc.). As a counterpart, it builds only for the platform where it is executed and can be significantly altered by local conditions (build tools local versions, dependency local versions etc.), thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<i>LocalCI </i> is generally faster than Server build, but slower than local plain build. CI workflow installs a complete build environment (compilers, sdk, build tools, containers, dependencies etc.) before running build system. It does not require to commit changes beforehand. However, it builds only for the platform where it is executed, thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<I>Server CI</i>, if successful, should guarantee success when publishing, as it occurs in conditions similar to release workflow (all platforms, complete build environment). As a counterpart, it is generally significantly slower than local builds and also implies to commit and push changes beforehand, even if the code is in unstable state.<br />
<br />
The recommended workflow thus strives to make the most of all stages:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
<br />
flowchart TD;<br />
<br />
fork(Fork Source repository in your own Github space)<br />
clone("Clone your fork locally</br><code>git clone...</code>")<br />
devel(Make modifications in your local fork)<br />
localBuild("<b>Run local plain build</b></br><code>cmake</code>, <code>make</code>...")<br />
localCI("<b>Run local CI</b></br><code>act</code>")<br />
git("Commit, Rebase & Push</br><code>git ...</code>")<br />
serverCI(<b>Run server CI</b></br><code>Github workflow</code>)<br />
PR(PR your changes to Source repository)<br />
<br />
fork-->clone<br />
clone-->devel<br />
devel-->localBuild<br />
localBuild-->localCI<br />
localCI-- "<i>Success</br>(including debug & tests)</i>" -->git<br />
git-->serverCI<br />
serverCI-- <i>Success</i> -->PR<br />
<br />
localBuild & localCI & serverCI ----> |<i>Failure</i>| devel<br />
<br />
classDef BUILD fill:#acc,stroke-width:4px;<br />
class localBuild BUILD;<br />
class localCI BUILD;<br />
class serverCI BUILD;<br />
<br />
}}<br />
<br />
This is the common process between all components. Each step will then be adapted to each component, as explained below.<br />
<br />
Comments:<br />
* Running local CI relies on [https://github.com/nektos/act <code>nektos/act</code>]<br />
* Rebase must be made against upstream directory (<code>git pull --rebase upstream <branch></code>)before pushing<br />
* Push must be made towards developer own fork. Caveat: do not try to push directly to upstream<br />
<br />
<br />
== Build External Dependencies ==<br />
<br />
=== Local Plain Build ===<br />
==== Caveats ====<br />
Dependency local plain build is possible but:<br />
* Local plain build IS NOT THE RECOMMENDED BUILD FOR FINAL DEPS. This build is solely intended for intermediary development and debugging. No support will be provided when used out-of-scope.<br />
* Local plain build has only been tested on Linux, with gcc >=14. For other platforms, adaptations should be necessary (contributions welcome). <br />
* Local plain build is much impacted by local particulars (local compiler version, dependencies already in cache or in system dirs etc.) and therefore does not guarantee further success for other builds.<br />
<br />
==== Prerequisites ====<br />
In addition with general [[#Prerequisites_2 | Prerequisites]], you'll need the OneAPI ISPC compiler.<br />
<br />
==== Conan cache interaction ====<br />
<br />
The build relies on the local Conan cache, which will be modified by the process. You may want to make a copy beforehand.<br />
<br />
In some scenarios, you may also want to reset your Conan cache (warning: may remove files unrelated to LuxCoreDeps):<br />
<pre>conan remove -c "*" # Be careful: may remove packages unrelated to LuxCoreDeps!</pre><br />
<br />
==== Run ====<br />
<br />
To run a plain local build, run the following statements in a console, from the root of LuxCoreDeps repository:<br />
<br />
<pre><br />
export RUNNER_OS=<os><br />
export RUNNER_ARCH=<arch><br />
<br />
export LUXDEPS_VERSION=test<br />
export GCC_VERSION=14 # Note: even for gcc > 14<br />
export WORKSPACE=.<br />
export CXX_VERSION=20<br />
export CMAKE_POLICY_VERSION_MINIMUM=3.25<br />
export DEPS_BUILD_TYPE=Debug # Or Release/RelWithDebInfo/MinSizeRel, as needed<br />
export cache_dir<br />
<br />
./run_conan.sh<br />
</pre><br />
<br />
with <code>RUNNER_OS</code>, <code>RUNNER_ARCH</code> in:<br />
* <code>Linux</code> / <code>X64</code><br />
* <code>Windows</code> / <code>X64</code><br />
* <code>macOS</code> / <code>X64</code><br />
* <code>macOS</code> / <code>ARM64</code><br />
reflecting your build platform.<br />
<br />
No detection is made (compiler, OS, arch...) . You'll have to do it on your own and set environment variables accordingly.<br />
<br />
==== Cleaning ====<br />
<br />
Conan will produce a bunch of scripts in the root of LuxCoreDeps repo. You can clean them with the following:<br />
<pre> ./utils/clean-conan-files.sh </pre><br />
<br />
=== Local Continuous Integration ===<br />
<br />
Run <code>act</code> on workflows located in <code>.github/workflows</code> folder, for instance <code>.github/workflows/build.yml</code> workflow.</br><br />
<br />
For more convenience, a wrapper script is also provided in <code>LuxCoreDeps</code> repository (Linux only, at the moment): <pre>./utils/local-CI-build.sh</pre><br />
<br />
=== Server Continuous Integration ===<br />
<br />
This process relies on the following Github workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/checker.yml <code>LuxCore Dependency Checker</code>].<br />
</br>Important points:<br />
* Your changes must have been committed and pushed to repository before.<br />
* The Checker workflow is actually also triggered on push event, so you may not have to run it by yourself<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
== Build LuxCore, Samples & Python Wheels ==<br />
<br />
=== Local Plain Build ===<br />
<br />
==== Prerequisites ====<br />
<br />
First, we will assume you have correctly completed the [[#Prerequisites_2 | Prerequisites]]. <br />
<br />
Second, we will also assume you've already git-cloned LuxCore on your local machine, opened a terminal, changed directory to LuxCore folder and git-checked out the branch that you want to build (+ for Windows: initialized build environment with <code>vcvarsall.bat</code>)<br />
<br />
==== Basic build ====<br />
<br />
Our build system internally relies on <code>cmake</code> but, for more convenience, everything has been wrapped into <code>make</code>-like statements.<br />
<br />
So, to build LuxCore, one just have to enter the following magic words:<br />
<pre><br />
make deps<br />
make<br />
</pre><br />
<br />
This should retrieve and install LuxCore dependencies, configure the project and run the build. That's all!<br />
<br />
<br />
For subsequent builds, if no modification have been made to dependencies, you'll just have to re-enter: <pre>make</pre><br />
<br />
==== Specific targets ====<br />
<br />
If you want to target a specific component, you can replace the above plain <code>make</code> by one of the following verbs:<br />
<pre>make luxcore</pre><br />
<pre>make pyluxcore</pre><br />
<pre>make luxcoreui</pre><br />
<pre>make luxcoreconsole</pre><br />
<br />
<br />
Starting from version 2.11, this method can build a "test wheel". This is a simplified wheel, only for current platform and current Python version, for testing purpose. The test wheel is particularly useful for developing/debugging LuxCore/BlendLuxCore integration.<br />
The verb is:<br />
<pre>make wheel-test</pre><br />
<br />
<br />
You can also build Doxygen documentation with the following statement:<br />
<pre>make doc</pre><br />
<br />
==== Build type ====<br />
<br />
By default, this method builds a release version, striped from all symbols. If you want to build a debug version, enter the following before any <code>make ...</code> command:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug</pre> <br />
<br />
==== Local dependency set ====<br />
<br />
It is possible to use a local dependency set, rather than relying on automatic downloading. It is especially useful for developing/debugging of LuxCoreDeps/LuxCore integration. In this case, one can replace the <code>make deps</code> statement by the following one:<br />
<br />
<pre><br />
python -m build-system.luxmake.deps --local <path/to/local/deps> --release <release><br />
</pre><br />
<br />
Nota: <code><release></code> is the release tag used by your local dependency set. If you build this set locally, it should likely be <code>test</code>.<br />
<br />
==== Cleaning ====<br />
<br />
You can remove build outputs with one of the following statement:<br />
<pre>make clean</pre><br />
or<br />
<pre>make clear</pre><br />
The former will remove build files, however preserving dependencies. <br />
The latter will remove everything and will require to reinstall dependencies (<code>make deps</code>).<br />
<br />
=== Local Continuous Integration ===<br />
<br />
This method is complementary to Local plain build, with the following additional capabilities:<br />
* test the LuxCore build in an environment close to the release environment (manylinux container, for instance)<br />
* can build wheels<br />
* debug any changes made to the build workflow<br />
<br />
It consists in running Github workflows locally, via <code>act</code>. Github workflows are located in <code>.github/workflows</code> folder.<br />
<br />
<code>act</code> invokation can be made on command line but, for convenience, a wrapper script is provided (for Linux): <pre>./build-helpers/debug/debug_wheels.sh</pre><br />
<br />
<i>Caveat: this build can produce wheels, but only for the host platform (no cross-compiling).</i><br />
<br />
=== Server Continuous Integration ===<br />
<br />
The process is nearly the same as publisher build, but the release steps are skipped. For that purpose, another Github workflow has to be executed: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-builder.yml <code>LuxCore Python Wheels Builder</code>].<br />
<br />
Please note that your changes must have been committed to repository before running the workflow.<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
= Publisher Workflows =<br />
<br />
== Prerequisites ==<br />
<br />
For these workflows, a Github account is required, with extended rights on the source repositories.<br />
<br />
== General Workflow ==<br />
<br />
The general workflow for publishing is in 3 parts:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
flowchart TD;<br />
subgraph Build["<center><b>BUILD & RELEASE DRAFT </br>(Run Releaser workflow)</b></center>"]<br />
padBuild(" "):::INVISIBLE<br />
repo("Go to <code>[Source repository]</code> on Github and open <code>Actions menu</code>")<br />
select("Select <code>[Releaser workflow]</code>")<br />
runwf(Click on <code>Run workflow</code> button, in the upper-right corner)<br />
branch(Select <code>Branch</code> in drop-down menu)<br />
options(Set workflow options)<br />
validate(Click <code>Run workflow</code>)<br />
wait(Wait for build to complete)<br />
end<br />
<br />
subgraph Release["<center><b>MAKE FINAL RELEASE</br>(Switch release to final status)</b></center>"]<br />
padRelease(" "):::INVISIBLE<br />
release("Open <code>[Release folder]</code>,</br> find the newly-built release (in Draft mode) </br> and edit it")<br />
complete(Add relevant information: change log, comments on version etc.)<br />
dedraft(Unset <code>Draft</code> checkbox)<br />
update(Click <code>Publish release</code>/<code>Update release</code> to finalize)<br />
end<br />
<br />
subgraph Deploy["<center><b>PUBLISH</br>(Run Publisher workflow)</b></center>"]<br />
padDeploy(" ")<br />
repoDeploy("Go to <code>[Source repository]</code> on Github and open <code>[Actions menu]</code>")<br />
selectDeploy("Select <code>[Publisher workflow]</code>")<br />
runwfDeploy("Click on <code>Run workflow</code> drop-down button, in the upper-right corner")<br />
choiceDeploy("Select <code>Branch</code>, set the <code>Tag to publish</code> and uncheck <code>Publish on Pypi Test</code> if needed")<br />
validateDeploy("Click on <code>Run workflow</code> button")<br />
waitDeploy("Wait for deployment to complete")<br />
end<br />
<br />
padBuild---repo<br />
repo-->select<br />
select-->runwf<br />
runwf-->branch<br />
branch-->options<br />
options-->validate<br />
validate-->wait:::WAIT<br />
linkStyle 0 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padRelease---release<br />
release-->complete<br />
complete-->dedraft<br />
dedraft-->update<br />
linkStyle 7 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padDeploy:::INVISIBLE---repoDeploy<br />
repoDeploy-->selectDeploy<br />
selectDeploy-->runwfDeploy<br />
runwfDeploy-->choiceDeploy<br />
choiceDeploy-->validateDeploy<br />
validateDeploy-->waitDeploy:::WAIT<br />
linkStyle 11 stroke:#fff,color:blue,stroke-width:0px;<br />
<br />
<br />
Build-- <i>if success</i> -->Release<br />
Release-- <i>if success & if needed</i> -->Deploy<br />
<br />
classDef WAIT fill:#ddd;<br />
classDef DEPS fill:#e4d8ff,stroke:#9488af;<br />
classDef INVISIBLE fill:#ffffffff,stroke:#ffffffff,stroke-width:0px,font-color:#ffffffff;<br />
classDef OPTIONAL stroke-dasharray: 5 5;<br />
<br />
class Deploy OPTIONAL;<br />
<br />
%% Note: padXXX is a poor hack to create a top-margin in subgraph...<br />
}}<br />
<br />
A few comments:<br />
* <code>[bracketed tokens]</code> refer to data specific to each component, which will be detailed below.<br />
* Publish part is optional, it will depends on the target<br />
* ''Caveat: if you provide an already-existing release version number during the process, the workflow will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.''<br />
<br />
== Per-target details ==<br />
<br />
=== External Dependencies ===<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreRender/LuxCoreDeps</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/release.yml <code>LuxCore Dependency Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCoreDeps/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
As a byproduct, External Dependencies are not intended to be deployed, so no Publisher workflow is provided.<br />
<br />
=== Python Wheels ===<br />
<br />
<br />
<br />
As far as wheels are concerned, in addition to building them, it is also necessary to upload them to [https://pypi.org/ PyPi] ("publish" them), so that they are available for [https://pypi.org/project/pip pip] installation.<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-releaser.yml <code>LuxCore Wheels Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-publisher.yml <code>LuxCore Wheels Publisher</code>]<br />
<br />
''Prerequisite: you must have released a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.''<br />
<br />
=== Samples ===<br />
<br />
As we plan to replace Samples by equivalent Python tools and thus deprecate them, the workflow has been limited to the Release part (no publish).<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/sample-releaser.yml <code>LuxCore Samples Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
=== BlendLuxCore ===<br />
<br />
<i>TODO</i><br />
<br />
= Version Management =<br />
<br />
== Semantic Versioning ==<br />
<br />
Starting for LuxCore version 2.10.0, we require that LuxCoreRender applies [https://semver.org/ Semantic Versioning]. Please strictly enforce this rule when incrementing version numbers.<br />
<br />
Remark: component versions does not have to be synced. For instance, in strict application of the standard, the newly created LuxCoreDeps will start at 1.0.0, while at the same time LuxCore is already at 2.10.0<br />
<br />
== Dependency Version pointer ==<br />
<br />
To make LuxCore know which version of dependencies it must be built against, we use a pointer.<br />
<br />
This pointer is stored in the file <code>build-helpers/build-settings.json</code>, under the path <code>Dependencies/release</code>.<br />
<br />
Make sure you keep it up-to-date when you upgrade LuxCore components.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender&diff=2701Building LuxCoreRender2026-04-28T03:10:04Z<p>Howetuft: /* Caveats */</p>
<hr />
<div>This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.<br />
<br />
LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all [[Building_LuxCoreRender_(legacy)|previous documents]] related to the compilation of older versions (<=2.9).<br />
<br />
<br />
<b>TL;DR</b> If you are just interested in a quick, local (but platform limited) compilation of LuxCore C++ samples or Python wheels, you may want to jump directly to [[#Build LuxCore, Samples & Python Wheels | Build LuxCore, Samples & Python Wheels]].</br><br />
<br />
<br />
<br />
= Audience =<br />
<br />
This document is intended for:<br />
* LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;<br />
* Developers wishing to contribute to the project;<br />
* External package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;<br />
<br />
This document assumes that the reader is skilled in the following areas:<br />
* C/C++ compilation<br />
* [https://cmake.org/ cmake]<br />
* [https://git-scm.com/ git]<br />
* [https://docs.github.com/en/actions/writing-workflows Github Workflows]<br />
* [https://packaging.python.org/en/latest/ Python Packaging], including [https://realpython.com/python-wheels/ Python Wheels format]<br />
<br />
Familiarity with [https://conan.io/ Conan] dependency manager may also help.<br />
<br />
</br><br />
This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries on the official [https://luxcorerender.org/download/ Download] page.<br />
<br />
= Build Targets =<br />
<br />
== Synoptic ==<br />
LuxCoreRender contains several build targets, below represented with dependency links:<br />
<br />
{{#mermaid:<br />
%%{<br />
init: {<br />
"theme": "forest",<br />
"logLevel": "info",<br />
"flowchart": {"curve": "basis"}<br />
}<br />
}%%<br />
<br />
flowchart LR;<br />
<br />
<br />
classDef TYPE font-weight:bold,font-size:1.1rem;<br />
classDef TARGET font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCOREDEPS fill:#ffe8ff,stroke:#9488af,font-weight:bold,font-size:1.1rem;<br />
classDef TARGETDEPS fill:#e4d8ff,stroke:#9488af,font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCORE fill:#bbceff,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETLUXCORE fill:#7799ee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef SAMPLES fill:#ffffdd,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETSAMPLES fill:#eeeecc,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef NEUTRAL fill:#fafafa,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETNEUTRAL fill:#eeeeee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef EXTDEP fill:#00000000,stroke:#00000000;<br />
<br />
<br />
subgraph Dependencies[External Dependencies]<br />
deps(LuxCore Dependencies)<br />
end<br />
<br />
class Dependencies LUXCOREDEPS;<br />
class deps TARGETDEPS;<br />
<br />
<br />
subgraph LuxCore<br />
lux(luxcore.so/.dll)<br />
luxa(luxcore.a)<br />
end<br />
class LuxCore LUXCORE;<br />
class lux TARGETLUXCORE;<br />
class luxa TARGETLUXCORE;<br />
<br />
subgraph Python_Wheels[Python Wheels]<br />
pylux(pyluxcore.so/.dll)<br />
wheels(LuxCore Python Wheels)<br />
end<br />
class Python_Wheels TYPE;<br />
class pylux TARGET;<br />
class wheels TARGET;<br />
<br />
subgraph Samples<br />
luxcoreui(luxcoreui)<br />
luxcoreconsole(luxcoreconsole)<br />
end<br />
class Samples SAMPLES;<br />
class luxcoreui TARGETSAMPLES;<br />
class luxcoreconsole TARGETSAMPLES;<br />
<br />
<br />
subgraph PyLuxCoreTools<br />
pyluxcon(pyluxcoreconsole)<br />
pyluxothers(...)<br />
end<br />
class PyLuxCoreTools NEUTRAL;<br />
class pyluxcon TARGETNEUTRAL;<br />
class pyluxothers TARGETNEUTRAL;<br />
<br />
subgraph Plugins[Python Plugins]<br />
blc(BlendLuxCore)<br />
otherplugins(...)<br />
end<br />
class blc TARGETNEUTRAL;<br />
class otherplugins TARGETNEUTRAL;<br />
<br />
class Plugins NEUTRAL;<br />
<br />
%% Warning: order matters<br />
deps-->lux<br />
deps-->luxa<br />
deps-->luxcoreui<br />
deps-->luxcoreconsole<br />
<br />
luxa--->pylux<br />
lux-->luxcoreui<br />
lux-->luxcoreconsole<br />
deps-->pylux<br />
<br />
<br />
<br />
pylux-->wheels<br />
wheels-. runtime .->blc<br />
wheels-. runtime .->otherplugins<br />
<br />
wheels-. runtime .->pyluxcon<br />
wheels-. runtime .->pyluxothers<br />
<br />
Python:::EXTDEP-->pylux<br />
<br />
<br />
%% Mermaid version: 8.14.0<br />
%% https://github.com/mermaid-js/mermaid/blob/8.14.0/src/defaultConfig.js<br />
<br />
<br />
<br />
}}<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! Target !! Source Repository !! Content<br />
|-<br />
| <b>External Dependencies</b>|| [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreDeps</code>] || A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to [https://github.com/LuxCoreRender/LuxCoreDeps/blob/main/README.md LuxCoreDeps README] for more information.<br />
|-<br />
| <b>LuxCore</b> || [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.<br />
|-<br />
| <b>Samples</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Sample C++ programs, illustrating luxcore use, namely <code>luxcoreconsole</code> and <code>luxcoreui</code><br />
|-<br />
| <b>Python Wheels</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version).</br> As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).<br />
|-<br />
| <b>Python Plugins</b>|| [https://github.com/LuxCoreRender/BlendLuxCore <code>BlendLuxCore</code>] etc. || Plugins to expose LuxCore in various external applications, notably Blender. </br> Written in Python and relying on Python Wheels as runtime dependency.<br />
|-<br />
| <b>PyLuxCoreTools</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python LuxCore Tools: set of command line tools based on pyluxcore, written in Python.<br />
|}<br />
<br />
== Targeted platforms ==<br />
<br />
LuxCoreRender aims at being available on the following 4 platforms:<br />
* Linux (glibc 2.28+)<br />
* Windows<br />
* MacOS Intel (>=10.15)<br />
* MacOS Arm (>=12.0)<br />
<br />
For Python-related targets, LuxCoreRender aims at being declined for [https://devguide.python.org/versions all Python versions supported at a given time].<br />
<br />
= Workflow Types =<br />
<br />
We distinguish between two types of build workflows:<br />
* Developer workflows<br />
* Publisher workflows<br />
<br />
<br />
''[[#Developer Workflows | Developer workflows]]'' are designed for development, debugging and test steps.<br />
<br />
Their purpose is to allow development and verify the code is ready for publication.<br />
<br />
<br />
''[[#Publisher Workflows | Publisher workflows]]'' are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.<br />
<br />
They exclusively take place in a CI/CD Github pipeline.<br />
<br />
These workflows are not designed for debugging or testing the underlying code. Execution of these workflows assumes that the development phase has been correctly completed and the underlying code is ready for final build and release. See [[#Developer Workflows | Developer Workflows]] to learn how to get code ready for final build.<br />
<br />
Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.<br />
<br />
= Developer Workflows =<br />
<br />
<br />
== Prerequisites ==<br />
<br />
<u>Tools</u><br />
<br />
You will need several build tools installed and referenced in the PATH.<br />
<br />
First, ensure you have a suitable toolchain:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! OS !! Compiler !! Minimal version<br />
|-<br />
| Windows || MSVC || 194x latest version<br />
|-<br />
| Linux|| gcc || 14<br />
|-<br />
| MacOS Intel|| XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|-<br />
| MacOS Arm || XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|}<br />
<br />
''Toolchain compliance is a very sensitive condition for a successful build. Before filing any claim, please check that your toolchain complies with the above requirements.''<br />
<br />
<br />
<br />
Then ensure the following software is also installed and available in your PATH:<br />
<br />
* [https://git-scm.com/ Git]<br />
* [https://cli.github.com/ Github CLI] (optional but recommended - for dependency signature checking)<br />
* [https://www.python.org/ Python 3] - any [https://devguide.python.org/versions/ currently supported version]<br />
* [https://conan.io Conan] latest version (pip install conan)<br />
* [https://github.com/pypa/wheel/tree/main Wheel] latest version (pip install wheel)<br />
* [https://cmake.org/ CMake] >= 3.29<br />
* [https://github.com/nektos/act nektos/act] (optional but recommended - for local build based on Github workflows)<br />
* [https://pypi.org/project/repairwheel repairwheel] (optional but recommended - for local build of test wheels)<br />
<br />
<br />
Platform specifics:<br />
* For Windows, ensure the command line is configured for building (<code>vcvarsall.bat</code>).<br />
* For Linux, you'll need <code>pkgconfig</code> in addition.<br />
* For MacOS, you'll need to ensure CC and CXX point to LLVM clang/clang++<br />
<br />
<u>Accounts</u><br />
<br />
A ''Github account'' is mandatory for LuxCore development.<br />
<br />
Following accounts are also recommended, in order to get in touch with LuxCore community:<br />
* [https://forums.luxcorerender.org/ LuxCoreRender Forums]<br />
* [https://discord.gg/chPGsKV LuxCoreRender Discord channel]<br />
<br />
== General Developer Workflow ==<br />
<br />
To compile and verify LuxCore component modifications in development process, there are 3 stages:<br />
* Local plain build: only run build system (cmake) on developer computer<br />
* Local Continuous Integration build: run full Continuous Integration workflow on developer computer<br />
* Server Continuous Integration build: run full Continuous Integration workflow on server<br />
<br />
<i>Local plain build</i> is generally faster than other builds and does not require to commit changes beforehand. Plain build installs a minimal build configuration (dependencies), but heavily relies on computer build environment for the rest (build tools, system libraries etc.). As a counterpart, it builds only for the platform where it is executed and can be significantly altered by local conditions (build tools local versions, dependency local versions etc.), thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<i>LocalCI </i> is generally faster than Server build, but slower than local plain build. CI workflow installs a complete build environment (compilers, sdk, build tools, containers, dependencies etc.) before running build system. It does not require to commit changes beforehand. However, it builds only for the platform where it is executed, thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<I>Server CI</i>, if successful, should guarantee success when publishing, as it occurs in conditions similar to release workflow (all platforms, complete build environment). As a counterpart, it is generally significantly slower than local builds and also implies to commit and push changes beforehand, even if the code is in unstable state.<br />
<br />
The recommended workflow thus strives to make the most of all stages:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
<br />
flowchart TD;<br />
<br />
fork(Fork Source repository in your own Github space)<br />
clone("Clone your fork locally</br><code>git clone...</code>")<br />
devel(Make modifications in your local fork)<br />
localBuild("<b>Run local plain build</b></br><code>cmake</code>, <code>make</code>...")<br />
localCI("<b>Run local CI</b></br><code>act</code>")<br />
git("Commit, Rebase & Push</br><code>git ...</code>")<br />
serverCI(<b>Run server CI</b></br><code>Github workflow</code>)<br />
PR(PR your changes to Source repository)<br />
<br />
fork-->clone<br />
clone-->devel<br />
devel-->localBuild<br />
localBuild-->localCI<br />
localCI-- "<i>Success</br>(including debug & tests)</i>" -->git<br />
git-->serverCI<br />
serverCI-- <i>Success</i> -->PR<br />
<br />
localBuild & localCI & serverCI ----> |<i>Failure</i>| devel<br />
<br />
classDef BUILD fill:#acc,stroke-width:4px;<br />
class localBuild BUILD;<br />
class localCI BUILD;<br />
class serverCI BUILD;<br />
<br />
}}<br />
<br />
This is the common process between all components. Each step will then be adapted to each component, as explained below.<br />
<br />
Comments:<br />
* Running local CI relies on [https://github.com/nektos/act <code>nektos/act</code>]<br />
* Rebase must be made against upstream directory (<code>git pull --rebase upstream <branch></code>)before pushing<br />
* Push must be made towards developer own fork. Caveat: do not try to push directly to upstream<br />
<br />
<br />
== Build External Dependencies ==<br />
<br />
=== Local Plain Build ===<br />
==== Caveats ====<br />
Dependency local plain build is possible but:<br />
* Local plain build IS NOT THE RECOMMENDED BUILD FOR FINAL DEPS. This build is solely intended for intermediary development and debugging. No support will be provided when used out-of-scope.<br />
* Local plain build has only be tested on Linux, with gcc >=14. For other platforms, adaptations should be necessary (contributions welcome). <br />
* Local plain build is much impacted by local particulars (local compiler version, dependencies already in cache or in system dirs etc.) and therefore does not guarantee further success for other (recommended) builds.<br />
<br />
==== Prerequisites ====<br />
In addition with general [[#Prerequisites_2 | Prerequisites]], you'll need the OneAPI ISPC compiler.<br />
<br />
==== Conan cache interaction ====<br />
<br />
The build relies on the local Conan cache, which will be modified by the process. You may want to make a copy beforehand.<br />
<br />
In some scenarios, you may also want to reset your Conan cache (warning: may remove files unrelated to LuxCoreDeps):<br />
<pre>conan remove -c "*" # Be careful: may remove packages unrelated to LuxCoreDeps!</pre><br />
<br />
==== Run ====<br />
<br />
To run a plain local build, run the following statements in a console, from the root of LuxCoreDeps repository:<br />
<br />
<pre><br />
export RUNNER_OS=<os><br />
export RUNNER_ARCH=<arch><br />
<br />
export LUXDEPS_VERSION=test<br />
export GCC_VERSION=14 # Note: even for gcc > 14<br />
export WORKSPACE=.<br />
export CXX_VERSION=20<br />
export CMAKE_POLICY_VERSION_MINIMUM=3.25<br />
export DEPS_BUILD_TYPE=Debug # Or Release/RelWithDebInfo/MinSizeRel, as needed<br />
export cache_dir<br />
<br />
./run_conan.sh<br />
</pre><br />
<br />
with <code>RUNNER_OS</code>, <code>RUNNER_ARCH</code> in:<br />
* <code>Linux</code> / <code>X64</code><br />
* <code>Windows</code> / <code>X64</code><br />
* <code>macOS</code> / <code>X64</code><br />
* <code>macOS</code> / <code>ARM64</code><br />
reflecting your build platform.<br />
<br />
No detection is made (compiler, OS, arch...) . You'll have to do it on your own and set environment variables accordingly.<br />
<br />
==== Cleaning ====<br />
<br />
Conan will produce a bunch of scripts in the root of LuxCoreDeps repo. You can clean them with the following:<br />
<pre> ./utils/clean-conan-files.sh </pre><br />
<br />
=== Local Continuous Integration ===<br />
<br />
Run <code>act</code> on workflows located in <code>.github/workflows</code> folder, for instance <code>.github/workflows/build.yml</code> workflow.</br><br />
<br />
For more convenience, a wrapper script is also provided in <code>LuxCoreDeps</code> repository (Linux only, at the moment): <pre>./utils/local-CI-build.sh</pre><br />
<br />
=== Server Continuous Integration ===<br />
<br />
This process relies on the following Github workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/checker.yml <code>LuxCore Dependency Checker</code>].<br />
</br>Important points:<br />
* Your changes must have been committed and pushed to repository before.<br />
* The Checker workflow is actually also triggered on push event, so you may not have to run it by yourself<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
== Build LuxCore, Samples & Python Wheels ==<br />
<br />
=== Local Plain Build ===<br />
<br />
==== Prerequisites ====<br />
<br />
First, we will assume you have correctly completed the [[#Prerequisites_2 | Prerequisites]]. <br />
<br />
Second, we will also assume you've already git-cloned LuxCore on your local machine, opened a terminal, changed directory to LuxCore folder and git-checked out the branch that you want to build (+ for Windows: initialized build environment with <code>vcvarsall.bat</code>)<br />
<br />
==== Basic build ====<br />
<br />
Our build system internally relies on <code>cmake</code> but, for more convenience, everything has been wrapped into <code>make</code>-like statements.<br />
<br />
So, to build LuxCore, one just have to enter the following magic words:<br />
<pre><br />
make deps<br />
make<br />
</pre><br />
<br />
This should retrieve and install LuxCore dependencies, configure the project and run the build. That's all!<br />
<br />
<br />
For subsequent builds, if no modification have been made to dependencies, you'll just have to re-enter: <pre>make</pre><br />
<br />
==== Specific targets ====<br />
<br />
If you want to target a specific component, you can replace the above plain <code>make</code> by one of the following verbs:<br />
<pre>make luxcore</pre><br />
<pre>make pyluxcore</pre><br />
<pre>make luxcoreui</pre><br />
<pre>make luxcoreconsole</pre><br />
<br />
<br />
Starting from version 2.11, this method can build a "test wheel". This is a simplified wheel, only for current platform and current Python version, for testing purpose. The test wheel is particularly useful for developing/debugging LuxCore/BlendLuxCore integration.<br />
The verb is:<br />
<pre>make wheel-test</pre><br />
<br />
<br />
You can also build Doxygen documentation with the following statement:<br />
<pre>make doc</pre><br />
<br />
==== Build type ====<br />
<br />
By default, this method builds a release version, striped from all symbols. If you want to build a debug version, enter the following before any <code>make ...</code> command:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug</pre> <br />
<br />
==== Local dependency set ====<br />
<br />
It is possible to use a local dependency set, rather than relying on automatic downloading. It is especially useful for developing/debugging of LuxCoreDeps/LuxCore integration. In this case, one can replace the <code>make deps</code> statement by the following one:<br />
<br />
<pre><br />
python -m build-system.luxmake.deps --local <path/to/local/deps> --release <release><br />
</pre><br />
<br />
Nota: <code><release></code> is the release tag used by your local dependency set. If you build this set locally, it should likely be <code>test</code>.<br />
<br />
==== Cleaning ====<br />
<br />
You can remove build outputs with one of the following statement:<br />
<pre>make clean</pre><br />
or<br />
<pre>make clear</pre><br />
The former will remove build files, however preserving dependencies. <br />
The latter will remove everything and will require to reinstall dependencies (<code>make deps</code>).<br />
<br />
=== Local Continuous Integration ===<br />
<br />
This method is complementary to Local plain build, with the following additional capabilities:<br />
* test the LuxCore build in an environment close to the release environment (manylinux container, for instance)<br />
* can build wheels<br />
* debug any changes made to the build workflow<br />
<br />
It consists in running Github workflows locally, via <code>act</code>. Github workflows are located in <code>.github/workflows</code> folder.<br />
<br />
<code>act</code> invokation can be made on command line but, for convenience, a wrapper script is provided (for Linux): <pre>./build-helpers/debug/debug_wheels.sh</pre><br />
<br />
<i>Caveat: this build can produce wheels, but only for the host platform (no cross-compiling).</i><br />
<br />
=== Server Continuous Integration ===<br />
<br />
The process is nearly the same as publisher build, but the release steps are skipped. For that purpose, another Github workflow has to be executed: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-builder.yml <code>LuxCore Python Wheels Builder</code>].<br />
<br />
Please note that your changes must have been committed to repository before running the workflow.<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
= Publisher Workflows =<br />
<br />
== Prerequisites ==<br />
<br />
For these workflows, a Github account is required, with extended rights on the source repositories.<br />
<br />
== General Workflow ==<br />
<br />
The general workflow for publishing is in 3 parts:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
flowchart TD;<br />
subgraph Build["<center><b>BUILD & RELEASE DRAFT </br>(Run Releaser workflow)</b></center>"]<br />
padBuild(" "):::INVISIBLE<br />
repo("Go to <code>[Source repository]</code> on Github and open <code>Actions menu</code>")<br />
select("Select <code>[Releaser workflow]</code>")<br />
runwf(Click on <code>Run workflow</code> button, in the upper-right corner)<br />
branch(Select <code>Branch</code> in drop-down menu)<br />
options(Set workflow options)<br />
validate(Click <code>Run workflow</code>)<br />
wait(Wait for build to complete)<br />
end<br />
<br />
subgraph Release["<center><b>MAKE FINAL RELEASE</br>(Switch release to final status)</b></center>"]<br />
padRelease(" "):::INVISIBLE<br />
release("Open <code>[Release folder]</code>,</br> find the newly-built release (in Draft mode) </br> and edit it")<br />
complete(Add relevant information: change log, comments on version etc.)<br />
dedraft(Unset <code>Draft</code> checkbox)<br />
update(Click <code>Publish release</code>/<code>Update release</code> to finalize)<br />
end<br />
<br />
subgraph Deploy["<center><b>PUBLISH</br>(Run Publisher workflow)</b></center>"]<br />
padDeploy(" ")<br />
repoDeploy("Go to <code>[Source repository]</code> on Github and open <code>[Actions menu]</code>")<br />
selectDeploy("Select <code>[Publisher workflow]</code>")<br />
runwfDeploy("Click on <code>Run workflow</code> drop-down button, in the upper-right corner")<br />
choiceDeploy("Select <code>Branch</code>, set the <code>Tag to publish</code> and uncheck <code>Publish on Pypi Test</code> if needed")<br />
validateDeploy("Click on <code>Run workflow</code> button")<br />
waitDeploy("Wait for deployment to complete")<br />
end<br />
<br />
padBuild---repo<br />
repo-->select<br />
select-->runwf<br />
runwf-->branch<br />
branch-->options<br />
options-->validate<br />
validate-->wait:::WAIT<br />
linkStyle 0 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padRelease---release<br />
release-->complete<br />
complete-->dedraft<br />
dedraft-->update<br />
linkStyle 7 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padDeploy:::INVISIBLE---repoDeploy<br />
repoDeploy-->selectDeploy<br />
selectDeploy-->runwfDeploy<br />
runwfDeploy-->choiceDeploy<br />
choiceDeploy-->validateDeploy<br />
validateDeploy-->waitDeploy:::WAIT<br />
linkStyle 11 stroke:#fff,color:blue,stroke-width:0px;<br />
<br />
<br />
Build-- <i>if success</i> -->Release<br />
Release-- <i>if success & if needed</i> -->Deploy<br />
<br />
classDef WAIT fill:#ddd;<br />
classDef DEPS fill:#e4d8ff,stroke:#9488af;<br />
classDef INVISIBLE fill:#ffffffff,stroke:#ffffffff,stroke-width:0px,font-color:#ffffffff;<br />
classDef OPTIONAL stroke-dasharray: 5 5;<br />
<br />
class Deploy OPTIONAL;<br />
<br />
%% Note: padXXX is a poor hack to create a top-margin in subgraph...<br />
}}<br />
<br />
A few comments:<br />
* <code>[bracketed tokens]</code> refer to data specific to each component, which will be detailed below.<br />
* Publish part is optional, it will depends on the target<br />
* ''Caveat: if you provide an already-existing release version number during the process, the workflow will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.''<br />
<br />
== Per-target details ==<br />
<br />
=== External Dependencies ===<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreRender/LuxCoreDeps</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/release.yml <code>LuxCore Dependency Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCoreDeps/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
As a byproduct, External Dependencies are not intended to be deployed, so no Publisher workflow is provided.<br />
<br />
=== Python Wheels ===<br />
<br />
<br />
<br />
As far as wheels are concerned, in addition to building them, it is also necessary to upload them to [https://pypi.org/ PyPi] ("publish" them), so that they are available for [https://pypi.org/project/pip pip] installation.<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-releaser.yml <code>LuxCore Wheels Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-publisher.yml <code>LuxCore Wheels Publisher</code>]<br />
<br />
''Prerequisite: you must have released a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.''<br />
<br />
=== Samples ===<br />
<br />
As we plan to replace Samples by equivalent Python tools and thus deprecate them, the workflow has been limited to the Release part (no publish).<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/sample-releaser.yml <code>LuxCore Samples Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
=== BlendLuxCore ===<br />
<br />
<i>TODO</i><br />
<br />
= Version Management =<br />
<br />
== Semantic Versioning ==<br />
<br />
Starting for LuxCore version 2.10.0, we require that LuxCoreRender applies [https://semver.org/ Semantic Versioning]. Please strictly enforce this rule when incrementing version numbers.<br />
<br />
Remark: component versions does not have to be synced. For instance, in strict application of the standard, the newly created LuxCoreDeps will start at 1.0.0, while at the same time LuxCore is already at 2.10.0<br />
<br />
== Dependency Version pointer ==<br />
<br />
To make LuxCore know which version of dependencies it must be built against, we use a pointer.<br />
<br />
This pointer is stored in the file <code>build-helpers/build-settings.json</code>, under the path <code>Dependencies/release</code>.<br />
<br />
Make sure you keep it up-to-date when you upgrade LuxCore components.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender&diff=2700Building LuxCoreRender2026-04-26T15:05:45Z<p>Howetuft: /* Run */</p>
<hr />
<div>This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.<br />
<br />
LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all [[Building_LuxCoreRender_(legacy)|previous documents]] related to the compilation of older versions (<=2.9).<br />
<br />
<br />
<b>TL;DR</b> If you are just interested in a quick, local (but platform limited) compilation of LuxCore C++ samples or Python wheels, you may want to jump directly to [[#Build LuxCore, Samples & Python Wheels | Build LuxCore, Samples & Python Wheels]].</br><br />
<br />
<br />
<br />
= Audience =<br />
<br />
This document is intended for:<br />
* LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;<br />
* Developers wishing to contribute to the project;<br />
* External package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;<br />
<br />
This document assumes that the reader is skilled in the following areas:<br />
* C/C++ compilation<br />
* [https://cmake.org/ cmake]<br />
* [https://git-scm.com/ git]<br />
* [https://docs.github.com/en/actions/writing-workflows Github Workflows]<br />
* [https://packaging.python.org/en/latest/ Python Packaging], including [https://realpython.com/python-wheels/ Python Wheels format]<br />
<br />
Familiarity with [https://conan.io/ Conan] dependency manager may also help.<br />
<br />
</br><br />
This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries on the official [https://luxcorerender.org/download/ Download] page.<br />
<br />
= Build Targets =<br />
<br />
== Synoptic ==<br />
LuxCoreRender contains several build targets, below represented with dependency links:<br />
<br />
{{#mermaid:<br />
%%{<br />
init: {<br />
"theme": "forest",<br />
"logLevel": "info",<br />
"flowchart": {"curve": "basis"}<br />
}<br />
}%%<br />
<br />
flowchart LR;<br />
<br />
<br />
classDef TYPE font-weight:bold,font-size:1.1rem;<br />
classDef TARGET font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCOREDEPS fill:#ffe8ff,stroke:#9488af,font-weight:bold,font-size:1.1rem;<br />
classDef TARGETDEPS fill:#e4d8ff,stroke:#9488af,font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCORE fill:#bbceff,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETLUXCORE fill:#7799ee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef SAMPLES fill:#ffffdd,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETSAMPLES fill:#eeeecc,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef NEUTRAL fill:#fafafa,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETNEUTRAL fill:#eeeeee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef EXTDEP fill:#00000000,stroke:#00000000;<br />
<br />
<br />
subgraph Dependencies[External Dependencies]<br />
deps(LuxCore Dependencies)<br />
end<br />
<br />
class Dependencies LUXCOREDEPS;<br />
class deps TARGETDEPS;<br />
<br />
<br />
subgraph LuxCore<br />
lux(luxcore.so/.dll)<br />
luxa(luxcore.a)<br />
end<br />
class LuxCore LUXCORE;<br />
class lux TARGETLUXCORE;<br />
class luxa TARGETLUXCORE;<br />
<br />
subgraph Python_Wheels[Python Wheels]<br />
pylux(pyluxcore.so/.dll)<br />
wheels(LuxCore Python Wheels)<br />
end<br />
class Python_Wheels TYPE;<br />
class pylux TARGET;<br />
class wheels TARGET;<br />
<br />
subgraph Samples<br />
luxcoreui(luxcoreui)<br />
luxcoreconsole(luxcoreconsole)<br />
end<br />
class Samples SAMPLES;<br />
class luxcoreui TARGETSAMPLES;<br />
class luxcoreconsole TARGETSAMPLES;<br />
<br />
<br />
subgraph PyLuxCoreTools<br />
pyluxcon(pyluxcoreconsole)<br />
pyluxothers(...)<br />
end<br />
class PyLuxCoreTools NEUTRAL;<br />
class pyluxcon TARGETNEUTRAL;<br />
class pyluxothers TARGETNEUTRAL;<br />
<br />
subgraph Plugins[Python Plugins]<br />
blc(BlendLuxCore)<br />
otherplugins(...)<br />
end<br />
class blc TARGETNEUTRAL;<br />
class otherplugins TARGETNEUTRAL;<br />
<br />
class Plugins NEUTRAL;<br />
<br />
%% Warning: order matters<br />
deps-->lux<br />
deps-->luxa<br />
deps-->luxcoreui<br />
deps-->luxcoreconsole<br />
<br />
luxa--->pylux<br />
lux-->luxcoreui<br />
lux-->luxcoreconsole<br />
deps-->pylux<br />
<br />
<br />
<br />
pylux-->wheels<br />
wheels-. runtime .->blc<br />
wheels-. runtime .->otherplugins<br />
<br />
wheels-. runtime .->pyluxcon<br />
wheels-. runtime .->pyluxothers<br />
<br />
Python:::EXTDEP-->pylux<br />
<br />
<br />
%% Mermaid version: 8.14.0<br />
%% https://github.com/mermaid-js/mermaid/blob/8.14.0/src/defaultConfig.js<br />
<br />
<br />
<br />
}}<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! Target !! Source Repository !! Content<br />
|-<br />
| <b>External Dependencies</b>|| [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreDeps</code>] || A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to [https://github.com/LuxCoreRender/LuxCoreDeps/blob/main/README.md LuxCoreDeps README] for more information.<br />
|-<br />
| <b>LuxCore</b> || [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.<br />
|-<br />
| <b>Samples</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Sample C++ programs, illustrating luxcore use, namely <code>luxcoreconsole</code> and <code>luxcoreui</code><br />
|-<br />
| <b>Python Wheels</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version).</br> As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).<br />
|-<br />
| <b>Python Plugins</b>|| [https://github.com/LuxCoreRender/BlendLuxCore <code>BlendLuxCore</code>] etc. || Plugins to expose LuxCore in various external applications, notably Blender. </br> Written in Python and relying on Python Wheels as runtime dependency.<br />
|-<br />
| <b>PyLuxCoreTools</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python LuxCore Tools: set of command line tools based on pyluxcore, written in Python.<br />
|}<br />
<br />
== Targeted platforms ==<br />
<br />
LuxCoreRender aims at being available on the following 4 platforms:<br />
* Linux (glibc 2.28+)<br />
* Windows<br />
* MacOS Intel (>=10.15)<br />
* MacOS Arm (>=12.0)<br />
<br />
For Python-related targets, LuxCoreRender aims at being declined for [https://devguide.python.org/versions all Python versions supported at a given time].<br />
<br />
= Workflow Types =<br />
<br />
We distinguish between two types of build workflows:<br />
* Developer workflows<br />
* Publisher workflows<br />
<br />
<br />
''[[#Developer Workflows | Developer workflows]]'' are designed for development, debugging and test steps.<br />
<br />
Their purpose is to allow development and verify the code is ready for publication.<br />
<br />
<br />
''[[#Publisher Workflows | Publisher workflows]]'' are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.<br />
<br />
They exclusively take place in a CI/CD Github pipeline.<br />
<br />
These workflows are not designed for debugging or testing the underlying code. Execution of these workflows assumes that the development phase has been correctly completed and the underlying code is ready for final build and release. See [[#Developer Workflows | Developer Workflows]] to learn how to get code ready for final build.<br />
<br />
Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.<br />
<br />
= Developer Workflows =<br />
<br />
<br />
== Prerequisites ==<br />
<br />
<u>Tools</u><br />
<br />
You will need several build tools installed and referenced in the PATH.<br />
<br />
First, ensure you have a suitable toolchain:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! OS !! Compiler !! Minimal version<br />
|-<br />
| Windows || MSVC || 194x latest version<br />
|-<br />
| Linux|| gcc || 14<br />
|-<br />
| MacOS Intel|| XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|-<br />
| MacOS Arm || XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|}<br />
<br />
''Toolchain compliance is a very sensitive condition for a successful build. Before filing any claim, please check that your toolchain complies with the above requirements.''<br />
<br />
<br />
<br />
Then ensure the following software is also installed and available in your PATH:<br />
<br />
* [https://git-scm.com/ Git]<br />
* [https://cli.github.com/ Github CLI] (optional but recommended - for dependency signature checking)<br />
* [https://www.python.org/ Python 3] - any [https://devguide.python.org/versions/ currently supported version]<br />
* [https://conan.io Conan] latest version (pip install conan)<br />
* [https://github.com/pypa/wheel/tree/main Wheel] latest version (pip install wheel)<br />
* [https://cmake.org/ CMake] >= 3.29<br />
* [https://github.com/nektos/act nektos/act] (optional but recommended - for local build based on Github workflows)<br />
* [https://pypi.org/project/repairwheel repairwheel] (optional but recommended - for local build of test wheels)<br />
<br />
<br />
Platform specifics:<br />
* For Windows, ensure the command line is configured for building (<code>vcvarsall.bat</code>).<br />
* For Linux, you'll need <code>pkgconfig</code> in addition.<br />
* For MacOS, you'll need to ensure CC and CXX point to LLVM clang/clang++<br />
<br />
<u>Accounts</u><br />
<br />
A ''Github account'' is mandatory for LuxCore development.<br />
<br />
Following accounts are also recommended, in order to get in touch with LuxCore community:<br />
* [https://forums.luxcorerender.org/ LuxCoreRender Forums]<br />
* [https://discord.gg/chPGsKV LuxCoreRender Discord channel]<br />
<br />
== General Developer Workflow ==<br />
<br />
To compile and verify LuxCore component modifications in development process, there are 3 stages:<br />
* Local plain build: only run build system (cmake) on developer computer<br />
* Local Continuous Integration build: run full Continuous Integration workflow on developer computer<br />
* Server Continuous Integration build: run full Continuous Integration workflow on server<br />
<br />
<i>Local plain build</i> is generally faster than other builds and does not require to commit changes beforehand. Plain build installs a minimal build configuration (dependencies), but heavily relies on computer build environment for the rest (build tools, system libraries etc.). As a counterpart, it builds only for the platform where it is executed and can be significantly altered by local conditions (build tools local versions, dependency local versions etc.), thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<i>LocalCI </i> is generally faster than Server build, but slower than local plain build. CI workflow installs a complete build environment (compilers, sdk, build tools, containers, dependencies etc.) before running build system. It does not require to commit changes beforehand. However, it builds only for the platform where it is executed, thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<I>Server CI</i>, if successful, should guarantee success when publishing, as it occurs in conditions similar to release workflow (all platforms, complete build environment). As a counterpart, it is generally significantly slower than local builds and also implies to commit and push changes beforehand, even if the code is in unstable state.<br />
<br />
The recommended workflow thus strives to make the most of all stages:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
<br />
flowchart TD;<br />
<br />
fork(Fork Source repository in your own Github space)<br />
clone("Clone your fork locally</br><code>git clone...</code>")<br />
devel(Make modifications in your local fork)<br />
localBuild("<b>Run local plain build</b></br><code>cmake</code>, <code>make</code>...")<br />
localCI("<b>Run local CI</b></br><code>act</code>")<br />
git("Commit, Rebase & Push</br><code>git ...</code>")<br />
serverCI(<b>Run server CI</b></br><code>Github workflow</code>)<br />
PR(PR your changes to Source repository)<br />
<br />
fork-->clone<br />
clone-->devel<br />
devel-->localBuild<br />
localBuild-->localCI<br />
localCI-- "<i>Success</br>(including debug & tests)</i>" -->git<br />
git-->serverCI<br />
serverCI-- <i>Success</i> -->PR<br />
<br />
localBuild & localCI & serverCI ----> |<i>Failure</i>| devel<br />
<br />
classDef BUILD fill:#acc,stroke-width:4px;<br />
class localBuild BUILD;<br />
class localCI BUILD;<br />
class serverCI BUILD;<br />
<br />
}}<br />
<br />
This is the common process between all components. Each step will then be adapted to each component, as explained below.<br />
<br />
Comments:<br />
* Running local CI relies on [https://github.com/nektos/act <code>nektos/act</code>]<br />
* Rebase must be made against upstream directory (<code>git pull --rebase upstream <branch></code>)before pushing<br />
* Push must be made towards developer own fork. Caveat: do not try to push directly to upstream<br />
<br />
<br />
== Build External Dependencies ==<br />
<br />
=== Local Plain Build ===<br />
==== Caveats ====<br />
Dependency local plain build is possible but:<br />
* Local plain build IS NOT THE RECOMMENDED BUILD for final deps. This build is solely intended for intermediary development and debugging. No support will be provided when used out-of-scope.<br />
* Local plain build has only be tested on Linux, with gcc >=14. For other platforms, adaptations should be necessary (contributions welcome). <br />
* Local plain build is much impacted by local particulars (local compiler version, dependencies already in cache or in system dirs etc.) and therefore does not guarantee further success for other (recommended) builds.<br />
<br />
==== Prerequisites ====<br />
In addition with general [[#Prerequisites_2 | Prerequisites]], you'll need the OneAPI ISPC compiler.<br />
<br />
==== Conan cache interaction ====<br />
<br />
The build relies on the local Conan cache, which will be modified by the process. You may want to make a copy beforehand.<br />
<br />
In some scenarios, you may also want to reset your Conan cache (warning: may remove files unrelated to LuxCoreDeps):<br />
<pre>conan remove -c "*" # Be careful: may remove packages unrelated to LuxCoreDeps!</pre><br />
<br />
==== Run ====<br />
<br />
To run a plain local build, run the following statements in a console, from the root of LuxCoreDeps repository:<br />
<br />
<pre><br />
export RUNNER_OS=<os><br />
export RUNNER_ARCH=<arch><br />
<br />
export LUXDEPS_VERSION=test<br />
export GCC_VERSION=14 # Note: even for gcc > 14<br />
export WORKSPACE=.<br />
export CXX_VERSION=20<br />
export CMAKE_POLICY_VERSION_MINIMUM=3.25<br />
export DEPS_BUILD_TYPE=Debug # Or Release/RelWithDebInfo/MinSizeRel, as needed<br />
export cache_dir<br />
<br />
./run_conan.sh<br />
</pre><br />
<br />
with <code>RUNNER_OS</code>, <code>RUNNER_ARCH</code> in:<br />
* <code>Linux</code> / <code>X64</code><br />
* <code>Windows</code> / <code>X64</code><br />
* <code>macOS</code> / <code>X64</code><br />
* <code>macOS</code> / <code>ARM64</code><br />
reflecting your build platform.<br />
<br />
No detection is made (compiler, OS, arch...) . You'll have to do it on your own and set environment variables accordingly.<br />
<br />
==== Cleaning ====<br />
<br />
Conan will produce a bunch of scripts in the root of LuxCoreDeps repo. You can clean them with the following:<br />
<pre> ./utils/clean-conan-files.sh </pre><br />
<br />
=== Local Continuous Integration ===<br />
<br />
Run <code>act</code> on workflows located in <code>.github/workflows</code> folder, for instance <code>.github/workflows/build.yml</code> workflow.</br><br />
<br />
For more convenience, a wrapper script is also provided in <code>LuxCoreDeps</code> repository (Linux only, at the moment): <pre>./utils/local-CI-build.sh</pre><br />
<br />
=== Server Continuous Integration ===<br />
<br />
This process relies on the following Github workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/checker.yml <code>LuxCore Dependency Checker</code>].<br />
</br>Important points:<br />
* Your changes must have been committed and pushed to repository before.<br />
* The Checker workflow is actually also triggered on push event, so you may not have to run it by yourself<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
== Build LuxCore, Samples & Python Wheels ==<br />
<br />
=== Local Plain Build ===<br />
<br />
==== Prerequisites ====<br />
<br />
First, we will assume you have correctly completed the [[#Prerequisites_2 | Prerequisites]]. <br />
<br />
Second, we will also assume you've already git-cloned LuxCore on your local machine, opened a terminal, changed directory to LuxCore folder and git-checked out the branch that you want to build (+ for Windows: initialized build environment with <code>vcvarsall.bat</code>)<br />
<br />
==== Basic build ====<br />
<br />
Our build system internally relies on <code>cmake</code> but, for more convenience, everything has been wrapped into <code>make</code>-like statements.<br />
<br />
So, to build LuxCore, one just have to enter the following magic words:<br />
<pre><br />
make deps<br />
make<br />
</pre><br />
<br />
This should retrieve and install LuxCore dependencies, configure the project and run the build. That's all!<br />
<br />
<br />
For subsequent builds, if no modification have been made to dependencies, you'll just have to re-enter: <pre>make</pre><br />
<br />
==== Specific targets ====<br />
<br />
If you want to target a specific component, you can replace the above plain <code>make</code> by one of the following verbs:<br />
<pre>make luxcore</pre><br />
<pre>make pyluxcore</pre><br />
<pre>make luxcoreui</pre><br />
<pre>make luxcoreconsole</pre><br />
<br />
<br />
Starting from version 2.11, this method can build a "test wheel". This is a simplified wheel, only for current platform and current Python version, for testing purpose. The test wheel is particularly useful for developing/debugging LuxCore/BlendLuxCore integration.<br />
The verb is:<br />
<pre>make wheel-test</pre><br />
<br />
<br />
You can also build Doxygen documentation with the following statement:<br />
<pre>make doc</pre><br />
<br />
==== Build type ====<br />
<br />
By default, this method builds a release version, striped from all symbols. If you want to build a debug version, enter the following before any <code>make ...</code> command:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug</pre> <br />
<br />
==== Local dependency set ====<br />
<br />
It is possible to use a local dependency set, rather than relying on automatic downloading. It is especially useful for developing/debugging of LuxCoreDeps/LuxCore integration. In this case, one can replace the <code>make deps</code> statement by the following one:<br />
<br />
<pre><br />
python -m build-system.luxmake.deps --local <path/to/local/deps> --release <release><br />
</pre><br />
<br />
Nota: <code><release></code> is the release tag used by your local dependency set. If you build this set locally, it should likely be <code>test</code>.<br />
<br />
==== Cleaning ====<br />
<br />
You can remove build outputs with one of the following statement:<br />
<pre>make clean</pre><br />
or<br />
<pre>make clear</pre><br />
The former will remove build files, however preserving dependencies. <br />
The latter will remove everything and will require to reinstall dependencies (<code>make deps</code>).<br />
<br />
=== Local Continuous Integration ===<br />
<br />
This method is complementary to Local plain build, with the following additional capabilities:<br />
* test the LuxCore build in an environment close to the release environment (manylinux container, for instance)<br />
* can build wheels<br />
* debug any changes made to the build workflow<br />
<br />
It consists in running Github workflows locally, via <code>act</code>. Github workflows are located in <code>.github/workflows</code> folder.<br />
<br />
<code>act</code> invokation can be made on command line but, for convenience, a wrapper script is provided (for Linux): <pre>./build-helpers/debug/debug_wheels.sh</pre><br />
<br />
<i>Caveat: this build can produce wheels, but only for the host platform (no cross-compiling).</i><br />
<br />
=== Server Continuous Integration ===<br />
<br />
The process is nearly the same as publisher build, but the release steps are skipped. For that purpose, another Github workflow has to be executed: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-builder.yml <code>LuxCore Python Wheels Builder</code>].<br />
<br />
Please note that your changes must have been committed to repository before running the workflow.<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
= Publisher Workflows =<br />
<br />
== Prerequisites ==<br />
<br />
For these workflows, a Github account is required, with extended rights on the source repositories.<br />
<br />
== General Workflow ==<br />
<br />
The general workflow for publishing is in 3 parts:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
flowchart TD;<br />
subgraph Build["<center><b>BUILD & RELEASE DRAFT </br>(Run Releaser workflow)</b></center>"]<br />
padBuild(" "):::INVISIBLE<br />
repo("Go to <code>[Source repository]</code> on Github and open <code>Actions menu</code>")<br />
select("Select <code>[Releaser workflow]</code>")<br />
runwf(Click on <code>Run workflow</code> button, in the upper-right corner)<br />
branch(Select <code>Branch</code> in drop-down menu)<br />
options(Set workflow options)<br />
validate(Click <code>Run workflow</code>)<br />
wait(Wait for build to complete)<br />
end<br />
<br />
subgraph Release["<center><b>MAKE FINAL RELEASE</br>(Switch release to final status)</b></center>"]<br />
padRelease(" "):::INVISIBLE<br />
release("Open <code>[Release folder]</code>,</br> find the newly-built release (in Draft mode) </br> and edit it")<br />
complete(Add relevant information: change log, comments on version etc.)<br />
dedraft(Unset <code>Draft</code> checkbox)<br />
update(Click <code>Publish release</code>/<code>Update release</code> to finalize)<br />
end<br />
<br />
subgraph Deploy["<center><b>PUBLISH</br>(Run Publisher workflow)</b></center>"]<br />
padDeploy(" ")<br />
repoDeploy("Go to <code>[Source repository]</code> on Github and open <code>[Actions menu]</code>")<br />
selectDeploy("Select <code>[Publisher workflow]</code>")<br />
runwfDeploy("Click on <code>Run workflow</code> drop-down button, in the upper-right corner")<br />
choiceDeploy("Select <code>Branch</code>, set the <code>Tag to publish</code> and uncheck <code>Publish on Pypi Test</code> if needed")<br />
validateDeploy("Click on <code>Run workflow</code> button")<br />
waitDeploy("Wait for deployment to complete")<br />
end<br />
<br />
padBuild---repo<br />
repo-->select<br />
select-->runwf<br />
runwf-->branch<br />
branch-->options<br />
options-->validate<br />
validate-->wait:::WAIT<br />
linkStyle 0 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padRelease---release<br />
release-->complete<br />
complete-->dedraft<br />
dedraft-->update<br />
linkStyle 7 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padDeploy:::INVISIBLE---repoDeploy<br />
repoDeploy-->selectDeploy<br />
selectDeploy-->runwfDeploy<br />
runwfDeploy-->choiceDeploy<br />
choiceDeploy-->validateDeploy<br />
validateDeploy-->waitDeploy:::WAIT<br />
linkStyle 11 stroke:#fff,color:blue,stroke-width:0px;<br />
<br />
<br />
Build-- <i>if success</i> -->Release<br />
Release-- <i>if success & if needed</i> -->Deploy<br />
<br />
classDef WAIT fill:#ddd;<br />
classDef DEPS fill:#e4d8ff,stroke:#9488af;<br />
classDef INVISIBLE fill:#ffffffff,stroke:#ffffffff,stroke-width:0px,font-color:#ffffffff;<br />
classDef OPTIONAL stroke-dasharray: 5 5;<br />
<br />
class Deploy OPTIONAL;<br />
<br />
%% Note: padXXX is a poor hack to create a top-margin in subgraph...<br />
}}<br />
<br />
A few comments:<br />
* <code>[bracketed tokens]</code> refer to data specific to each component, which will be detailed below.<br />
* Publish part is optional, it will depends on the target<br />
* ''Caveat: if you provide an already-existing release version number during the process, the workflow will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.''<br />
<br />
== Per-target details ==<br />
<br />
=== External Dependencies ===<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreRender/LuxCoreDeps</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/release.yml <code>LuxCore Dependency Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCoreDeps/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
As a byproduct, External Dependencies are not intended to be deployed, so no Publisher workflow is provided.<br />
<br />
=== Python Wheels ===<br />
<br />
<br />
<br />
As far as wheels are concerned, in addition to building them, it is also necessary to upload them to [https://pypi.org/ PyPi] ("publish" them), so that they are available for [https://pypi.org/project/pip pip] installation.<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-releaser.yml <code>LuxCore Wheels Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-publisher.yml <code>LuxCore Wheels Publisher</code>]<br />
<br />
''Prerequisite: you must have released a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.''<br />
<br />
=== Samples ===<br />
<br />
As we plan to replace Samples by equivalent Python tools and thus deprecate them, the workflow has been limited to the Release part (no publish).<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/sample-releaser.yml <code>LuxCore Samples Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
=== BlendLuxCore ===<br />
<br />
<i>TODO</i><br />
<br />
= Version Management =<br />
<br />
== Semantic Versioning ==<br />
<br />
Starting for LuxCore version 2.10.0, we require that LuxCoreRender applies [https://semver.org/ Semantic Versioning]. Please strictly enforce this rule when incrementing version numbers.<br />
<br />
Remark: component versions does not have to be synced. For instance, in strict application of the standard, the newly created LuxCoreDeps will start at 1.0.0, while at the same time LuxCore is already at 2.10.0<br />
<br />
== Dependency Version pointer ==<br />
<br />
To make LuxCore know which version of dependencies it must be built against, we use a pointer.<br />
<br />
This pointer is stored in the file <code>build-helpers/build-settings.json</code>, under the path <code>Dependencies/release</code>.<br />
<br />
Make sure you keep it up-to-date when you upgrade LuxCore components.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2699Building LuxCoreRender - FAQ2026-04-26T14:44:07Z<p>Howetuft: /* How can I build a sanitized version of LuxCore? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies in local, you may want to inject them in LuxCore build. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)<br />
<br />
== How can I build a sanitized version of LuxCore? ==<br />
<br />
It is possible to build a sanitized version of LuxCore, including <code>luxcoreui</code>, <code>luxcoreconsole</code>, <code>pyluxcore</code> and the wheels.<br />
It just consists in setting the environment variable <code>LUX_SANITIZE</code> before the build:<br />
<br />
<pre>export LUX_SANITIZE=1 # or whatever value you want</pre><br />
<br />
To come back to unsanitized build, just <code>unset LUX_SANITIZE</code>.<br />
<br />
2 caveats:<br />
* You'll need to export the following before running LuxCore:<br />
<pre>ASAN_OPTIONS=protect_shadow_gap=0</pre><br />
otherwise LuxCore will stop early with the following error message:<br />
<pre>terminate called after throwing an instance of 'std::runtime_error'<br />
what(): CUDA driver API error CUDA_ERROR_NOT_INITIALIZED<br />
</pre><br />
* Unfortunately, sanitized version of the wheel will not do with Blender, as Blender has special code to control sanitizing and will override ours.<br />
<br />
== In Linux, I try to set an environment variable that should control LuxCore build, but it does not work ==<br />
<br />
In Linux, for LuxCore build system to take them into account, the environment variables that control the build (LUX_BUILD_TYPE, LUX_SANITIZE...) should not only be set, but also exported:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug # `set LUX_BUILD_TYPE=Debug` would be insufficient</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2698Building LuxCoreRender - FAQ2026-04-26T14:42:31Z<p>Howetuft: /* Can I generate debug information for dependencies (LuxCoreDeps)? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies in local, you may want to inject them in LuxCore build. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)<br />
<br />
== How can I build a sanitized version of LuxCore? ==<br />
<br />
It is possible to build a sanitized version of LuxCore, including <code>luxcoreui</code>, <code>luxcoreconsole</code>, <code>pyluxcore</code> and the wheels.<br />
It just consists in setting the environment variable <code>LUX_SANITIZE</code>:<br />
<br />
<pre>export LUX_SANITIZE=1 # or whatever value you want</pre><br />
<br />
To come back to unsanitized build, just <code>unset LUX_SANITIZE</code>.<br />
<br />
2 caveats:<br />
* You'll need to export the following before running LuxCore:<br />
<pre>ASAN_OPTIONS=protect_shadow_gap=0</pre><br />
otherwise LuxCore will stop early with the following error message:<br />
<pre>terminate called after throwing an instance of 'std::runtime_error'<br />
what(): CUDA driver API error CUDA_ERROR_NOT_INITIALIZED<br />
</pre><br />
* Unfortunately, sanitized version of the wheel will not do with Blender, as Blender has special code to control sanitizing and will override ours.<br />
<br />
== In Linux, I try to set an environment variable that should control LuxCore build, but it does not work ==<br />
<br />
In Linux, for LuxCore build system to take them into account, the environment variables that control the build (LUX_BUILD_TYPE, LUX_SANITIZE...) should not only be set, but also exported:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug # `set LUX_BUILD_TYPE=Debug` would be insufficient</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2697Building LuxCoreRender - FAQ2026-04-26T09:07:17Z<p>Howetuft: /* How can I build a sanitized version of LuxCore? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies in local, you may want to inject them in LuxCore. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)<br />
<br />
== How can I build a sanitized version of LuxCore? ==<br />
<br />
It is possible to build a sanitized version of LuxCore, including <code>luxcoreui</code>, <code>luxcoreconsole</code>, <code>pyluxcore</code> and the wheels.<br />
It just consists in setting the environment variable <code>LUX_SANITIZE</code>:<br />
<br />
<pre>export LUX_SANITIZE=1 # or whatever value you want</pre><br />
<br />
To come back to unsanitized build, just <code>unset LUX_SANITIZE</code>.<br />
<br />
2 caveats:<br />
* You'll need to export the following before running LuxCore:<br />
<pre>ASAN_OPTIONS=protect_shadow_gap=0</pre><br />
otherwise LuxCore will stop early with the following error message:<br />
<pre>terminate called after throwing an instance of 'std::runtime_error'<br />
what(): CUDA driver API error CUDA_ERROR_NOT_INITIALIZED<br />
</pre><br />
* Unfortunately, sanitized version of the wheel will not do with Blender, as Blender has special code to control sanitizing and will override ours.<br />
<br />
== In Linux, I try to set an environment variable that should control LuxCore build, but it does not work ==<br />
<br />
In Linux, for LuxCore build system to take them into account, the environment variables that control the build (LUX_BUILD_TYPE, LUX_SANITIZE...) should not only be set, but also exported:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug # `set LUX_BUILD_TYPE=Debug` would be insufficient</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2696Building LuxCoreRender - FAQ2026-04-26T09:06:33Z<p>Howetuft: /* Can I build a sanitized version of LuxCore? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies in local, you may want to inject them in LuxCore. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)<br />
<br />
== How can I build a sanitized version of LuxCore? ==<br />
<br />
It is possible to build a sanitized version of LuxCore, including <code>luxcoreui</code>, <code>luxcoreconsole</code>, <code>pyluxcore</code> and the wheels.<br />
It just consists in setting the environment variable <code>LUX_SANITIZE</code>:<br />
<br />
<pre>export LUX_SANITIZE=1 # or whatever value you want</pre><br />
<br />
2 caveats:<br />
* To come back to unsanitized build, you must <code>unset LUX_SANITIZE</code>.<br />
* You'll need to export the following before running LuxCore:<br />
<pre>ASAN_OPTIONS=protect_shadow_gap=0</pre><br />
otherwise LuxCore will stop early with the following error message:<br />
<pre>terminate called after throwing an instance of 'std::runtime_error'<br />
what(): CUDA driver API error CUDA_ERROR_NOT_INITIALIZED<br />
</pre><br />
* Unfortunately, sanitized version of the wheel will not do with Blender, as Blender has special code to control sanitizing and will override ours.<br />
<br />
== In Linux, I try to set an environment variable that should control LuxCore build, but it does not work ==<br />
<br />
In Linux, for LuxCore build system to take them into account, the environment variables that control the build (LUX_BUILD_TYPE, LUX_SANITIZE...) should not only be set, but also exported:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug # `set LUX_BUILD_TYPE=Debug` would be insufficient</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2695Building LuxCoreRender - FAQ2026-04-26T09:05:42Z<p>Howetuft: </p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies in local, you may want to inject them in LuxCore. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)<br />
<br />
== Can I build a sanitized version of LuxCore? ==<br />
<br />
It is possible to build a sanitized version of LuxCore, including <code>luxcoreui</code>, <code>luxcoreconsole</code>, <code>pyluxcore</code> and the wheels.<br />
It just consists in setting the environment variable <code>LUX_SANITIZE</code>:<br />
<br />
<pre>export LUX_SANITIZE=1 # or whatever value you want</pre><br />
<br />
2 caveats:<br />
* To come back to unsanitized build, you must <code>unset LUX_SANITIZE</code>.<br />
* You'll need to export the following before running LuxCore:<br />
<pre>ASAN_OPTIONS=protect_shadow_gap=0</pre><br />
otherwise LuxCore will stop early with the following error message:<br />
<pre>terminate called after throwing an instance of 'std::runtime_error'<br />
what(): CUDA driver API error CUDA_ERROR_NOT_INITIALIZED<br />
</pre><br />
* Unfortunately, sanitized version of the wheel will not do with Blender, as Blender has special code to control sanitizing and will override ours.<br />
<br />
<br />
== In Linux, I try to set an environment variable that should control LuxCore build, but it does not work ==<br />
<br />
In Linux, for LuxCore build system to take them into account, the environment variables that control the build (LUX_BUILD_TYPE, LUX_SANITIZE...) should not only be set, but also exported:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug # `set LUX_BUILD_TYPE=Debug` would be insufficient</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2694Building LuxCoreRender - FAQ2026-04-26T08:45:35Z<p>Howetuft: </p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies in local, you may want to inject them in LuxCore. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)<br />
<br />
== Can I build a sanitized version of LuxCore? ==<br />
<br />
It is possible to build a sanitized version of LuxCore, including <code>luxcoreui</code>, <code>luxcoreconsole</code>, <code>pyluxcore</code> and the wheels.<br />
It just consists in setting the environment variable <code>LUX_SANITIZE</code>:<br />
<br />
<pre>export LUX_SANITIZE=1 # or whatever value you want</pre><br />
<br />
2 caveats:<br />
- To come back to unsanitized build, you must <code>unset LUX_SANITIZE</code>.<br />
- Unfortunately, sanitized version of the wheel will not do with Blender, as Blender has special code to control sanitizing and will override our settings.<br />
<br />
<br />
== In Linux, I try to set an environment variable that should control LuxCore build, but it does not work ==<br />
<br />
In Linux, for LuxCore build system to take them into account, the environment variables that control the build (LUX_BUILD_TYPE, LUX_SANITIZE...) should not only be set, but also exported:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug # `set LUX_BUILD_TYPE=Debug` would be insufficient</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2693Building LuxCoreRender - FAQ2026-04-26T08:40:01Z<p>Howetuft: /* Can I build a sanitized version of LuxCore? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies in local, you may want to inject them in LuxCore. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)<br />
<br />
== Can I build a sanitized version of LuxCore? ==<br />
<br />
It is possible to build a sanitized version of LuxCore, including <code>luxcoreui</code>, <code>luxcoreconsole</code>, <code>pyluxcore</code> and the wheels.<br />
It just consists in setting the environment variable <code>LUX_SANITIZE</code>:<br />
<br />
<pre>export LUX_SANITIZE=1 # or whatever value you want</pre><br />
<br />
2 caveats:<br />
- To come back to unsanitized build, you must <code>unset LUX_SANITIZE</code>.<br />
- Unfortunately, sanitized version of the wheel will not do with Blender, as Blender has special code to control sanitizing and will override our settings.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2692Building LuxCoreRender - FAQ2026-04-26T08:39:17Z<p>Howetuft: </p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies in local, you may want to inject them in LuxCore. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)<br />
<br />
== Can I build a sanitized version of LuxCore? ==<br />
<br />
It is possible to build a sanitized version of LuxCore, including `luxcoreui`, `luxcoreconsole`, `pyluxcore` and the wheels.<br />
It just consists in setting the environment variable <code>LUX_SANITIZE</code>:<br />
<br />
<pre>export LUX_SANITIZE=1 # or whatever value you want</pre><br />
<br />
2 caveats:<br />
- To come back to unsanitized build, you must <code>unset LUX_SANITIZE</code>.<br />
- Unfortunately, sanitized version of the wheel will not do with Blender, as Blender has special code to control sanitizing and will override our settings.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2691Building LuxCoreRender - FAQ2026-04-26T08:31:29Z<p>Howetuft: /* Can I generate debug information for dependencies (LuxCoreDeps)? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies in local, you may want to inject them in LuxCore. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2690Building LuxCoreRender - FAQ2026-04-26T08:31:01Z<p>Howetuft: /* Can I generate debug information for dependencies (LuxCoreDeps)? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies, you may want to inject them in LuxCore. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2689Building LuxCoreRender - FAQ2026-04-24T19:43:11Z<p>Howetuft: /* Can I generate debug information for dependencies (LuxCoreDeps)? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local dependency build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies, you may want to inject them in LuxCore. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre><br />
<br />
(this replaces <code>make deps</code>)</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2688Building LuxCoreRender - FAQ2026-04-24T19:42:37Z<p>Howetuft: /* Can I generate debug information for dependencies (LuxCoreDeps)? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local dependency build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies, you may want to inject them in LuxCore. This can be done with the following:<br />
<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test --build-type=Debug</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2687Building LuxCoreRender - FAQ2026-04-24T19:41:27Z<p>Howetuft: /* Can I generate debug information for dependencies (LuxCoreDeps)? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local dependency build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre><br />
<br />
<br />
After having built dependencies, you may want to inject them in LuxCore. This can be done with the following</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2686Building LuxCoreRender - FAQ2026-04-24T19:01:01Z<p>Howetuft: /* Can I use git bisect? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit in <code>LuxCore</code>, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local dependency build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2685Building LuxCoreRender - FAQ2026-04-24T18:50:22Z<p>Howetuft: /* Is it possible to set-up a local-only, end-to-end, build chain? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake.deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local dependency build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender&diff=2684Building LuxCoreRender2026-04-24T04:19:31Z<p>Howetuft: /* Run */</p>
<hr />
<div>This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.<br />
<br />
LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all [[Building_LuxCoreRender_(legacy)|previous documents]] related to the compilation of older versions (<=2.9).<br />
<br />
<br />
<b>TL;DR</b> If you are just interested in a quick, local (but platform limited) compilation of LuxCore C++ samples or Python wheels, you may want to jump directly to [[#Build LuxCore, Samples & Python Wheels | Build LuxCore, Samples & Python Wheels]].</br><br />
<br />
<br />
<br />
= Audience =<br />
<br />
This document is intended for:<br />
* LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;<br />
* Developers wishing to contribute to the project;<br />
* External package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;<br />
<br />
This document assumes that the reader is skilled in the following areas:<br />
* C/C++ compilation<br />
* [https://cmake.org/ cmake]<br />
* [https://git-scm.com/ git]<br />
* [https://docs.github.com/en/actions/writing-workflows Github Workflows]<br />
* [https://packaging.python.org/en/latest/ Python Packaging], including [https://realpython.com/python-wheels/ Python Wheels format]<br />
<br />
Familiarity with [https://conan.io/ Conan] dependency manager may also help.<br />
<br />
</br><br />
This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries on the official [https://luxcorerender.org/download/ Download] page.<br />
<br />
= Build Targets =<br />
<br />
== Synoptic ==<br />
LuxCoreRender contains several build targets, below represented with dependency links:<br />
<br />
{{#mermaid:<br />
%%{<br />
init: {<br />
"theme": "forest",<br />
"logLevel": "info",<br />
"flowchart": {"curve": "basis"}<br />
}<br />
}%%<br />
<br />
flowchart LR;<br />
<br />
<br />
classDef TYPE font-weight:bold,font-size:1.1rem;<br />
classDef TARGET font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCOREDEPS fill:#ffe8ff,stroke:#9488af,font-weight:bold,font-size:1.1rem;<br />
classDef TARGETDEPS fill:#e4d8ff,stroke:#9488af,font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCORE fill:#bbceff,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETLUXCORE fill:#7799ee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef SAMPLES fill:#ffffdd,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETSAMPLES fill:#eeeecc,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef NEUTRAL fill:#fafafa,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETNEUTRAL fill:#eeeeee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef EXTDEP fill:#00000000,stroke:#00000000;<br />
<br />
<br />
subgraph Dependencies[External Dependencies]<br />
deps(LuxCore Dependencies)<br />
end<br />
<br />
class Dependencies LUXCOREDEPS;<br />
class deps TARGETDEPS;<br />
<br />
<br />
subgraph LuxCore<br />
lux(luxcore.so/.dll)<br />
luxa(luxcore.a)<br />
end<br />
class LuxCore LUXCORE;<br />
class lux TARGETLUXCORE;<br />
class luxa TARGETLUXCORE;<br />
<br />
subgraph Python_Wheels[Python Wheels]<br />
pylux(pyluxcore.so/.dll)<br />
wheels(LuxCore Python Wheels)<br />
end<br />
class Python_Wheels TYPE;<br />
class pylux TARGET;<br />
class wheels TARGET;<br />
<br />
subgraph Samples<br />
luxcoreui(luxcoreui)<br />
luxcoreconsole(luxcoreconsole)<br />
end<br />
class Samples SAMPLES;<br />
class luxcoreui TARGETSAMPLES;<br />
class luxcoreconsole TARGETSAMPLES;<br />
<br />
<br />
subgraph PyLuxCoreTools<br />
pyluxcon(pyluxcoreconsole)<br />
pyluxothers(...)<br />
end<br />
class PyLuxCoreTools NEUTRAL;<br />
class pyluxcon TARGETNEUTRAL;<br />
class pyluxothers TARGETNEUTRAL;<br />
<br />
subgraph Plugins[Python Plugins]<br />
blc(BlendLuxCore)<br />
otherplugins(...)<br />
end<br />
class blc TARGETNEUTRAL;<br />
class otherplugins TARGETNEUTRAL;<br />
<br />
class Plugins NEUTRAL;<br />
<br />
%% Warning: order matters<br />
deps-->lux<br />
deps-->luxa<br />
deps-->luxcoreui<br />
deps-->luxcoreconsole<br />
<br />
luxa--->pylux<br />
lux-->luxcoreui<br />
lux-->luxcoreconsole<br />
deps-->pylux<br />
<br />
<br />
<br />
pylux-->wheels<br />
wheels-. runtime .->blc<br />
wheels-. runtime .->otherplugins<br />
<br />
wheels-. runtime .->pyluxcon<br />
wheels-. runtime .->pyluxothers<br />
<br />
Python:::EXTDEP-->pylux<br />
<br />
<br />
%% Mermaid version: 8.14.0<br />
%% https://github.com/mermaid-js/mermaid/blob/8.14.0/src/defaultConfig.js<br />
<br />
<br />
<br />
}}<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! Target !! Source Repository !! Content<br />
|-<br />
| <b>External Dependencies</b>|| [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreDeps</code>] || A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to [https://github.com/LuxCoreRender/LuxCoreDeps/blob/main/README.md LuxCoreDeps README] for more information.<br />
|-<br />
| <b>LuxCore</b> || [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.<br />
|-<br />
| <b>Samples</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Sample C++ programs, illustrating luxcore use, namely <code>luxcoreconsole</code> and <code>luxcoreui</code><br />
|-<br />
| <b>Python Wheels</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version).</br> As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).<br />
|-<br />
| <b>Python Plugins</b>|| [https://github.com/LuxCoreRender/BlendLuxCore <code>BlendLuxCore</code>] etc. || Plugins to expose LuxCore in various external applications, notably Blender. </br> Written in Python and relying on Python Wheels as runtime dependency.<br />
|-<br />
| <b>PyLuxCoreTools</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python LuxCore Tools: set of command line tools based on pyluxcore, written in Python.<br />
|}<br />
<br />
== Targeted platforms ==<br />
<br />
LuxCoreRender aims at being available on the following 4 platforms:<br />
* Linux (glibc 2.28+)<br />
* Windows<br />
* MacOS Intel (>=10.15)<br />
* MacOS Arm (>=12.0)<br />
<br />
For Python-related targets, LuxCoreRender aims at being declined for [https://devguide.python.org/versions all Python versions supported at a given time].<br />
<br />
= Workflow Types =<br />
<br />
We distinguish between two types of build workflows:<br />
* Developer workflows<br />
* Publisher workflows<br />
<br />
<br />
''[[#Developer Workflows | Developer workflows]]'' are designed for development, debugging and test steps.<br />
<br />
Their purpose is to allow development and verify the code is ready for publication.<br />
<br />
<br />
''[[#Publisher Workflows | Publisher workflows]]'' are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.<br />
<br />
They exclusively take place in a CI/CD Github pipeline.<br />
<br />
These workflows are not designed for debugging or testing the underlying code. Execution of these workflows assumes that the development phase has been correctly completed and the underlying code is ready for final build and release. See [[#Developer Workflows | Developer Workflows]] to learn how to get code ready for final build.<br />
<br />
Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.<br />
<br />
= Developer Workflows =<br />
<br />
<br />
== Prerequisites ==<br />
<br />
<u>Tools</u><br />
<br />
You will need several build tools installed and referenced in the PATH.<br />
<br />
First, ensure you have a suitable toolchain:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! OS !! Compiler !! Minimal version<br />
|-<br />
| Windows || MSVC || 194x latest version<br />
|-<br />
| Linux|| gcc || 14<br />
|-<br />
| MacOS Intel|| XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|-<br />
| MacOS Arm || XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|}<br />
<br />
''Toolchain compliance is a very sensitive condition for a successful build. Before filing any claim, please check that your toolchain complies with the above requirements.''<br />
<br />
<br />
<br />
Then ensure the following software is also installed and available in your PATH:<br />
<br />
* [https://git-scm.com/ Git]<br />
* [https://cli.github.com/ Github CLI] (optional but recommended - for dependency signature checking)<br />
* [https://www.python.org/ Python 3] - any [https://devguide.python.org/versions/ currently supported version]<br />
* [https://conan.io Conan] latest version (pip install conan)<br />
* [https://github.com/pypa/wheel/tree/main Wheel] latest version (pip install wheel)<br />
* [https://cmake.org/ CMake] >= 3.29<br />
* [https://github.com/nektos/act nektos/act] (optional but recommended - for local build based on Github workflows)<br />
* [https://pypi.org/project/repairwheel repairwheel] (optional but recommended - for local build of test wheels)<br />
<br />
<br />
Platform specifics:<br />
* For Windows, ensure the command line is configured for building (<code>vcvarsall.bat</code>).<br />
* For Linux, you'll need <code>pkgconfig</code> in addition.<br />
* For MacOS, you'll need to ensure CC and CXX point to LLVM clang/clang++<br />
<br />
<u>Accounts</u><br />
<br />
A ''Github account'' is mandatory for LuxCore development.<br />
<br />
Following accounts are also recommended, in order to get in touch with LuxCore community:<br />
* [https://forums.luxcorerender.org/ LuxCoreRender Forums]<br />
* [https://discord.gg/chPGsKV LuxCoreRender Discord channel]<br />
<br />
== General Developer Workflow ==<br />
<br />
To compile and verify LuxCore component modifications in development process, there are 3 stages:<br />
* Local plain build: only run build system (cmake) on developer computer<br />
* Local Continuous Integration build: run full Continuous Integration workflow on developer computer<br />
* Server Continuous Integration build: run full Continuous Integration workflow on server<br />
<br />
<i>Local plain build</i> is generally faster than other builds and does not require to commit changes beforehand. Plain build installs a minimal build configuration (dependencies), but heavily relies on computer build environment for the rest (build tools, system libraries etc.). As a counterpart, it builds only for the platform where it is executed and can be significantly altered by local conditions (build tools local versions, dependency local versions etc.), thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<i>LocalCI </i> is generally faster than Server build, but slower than local plain build. CI workflow installs a complete build environment (compilers, sdk, build tools, containers, dependencies etc.) before running build system. It does not require to commit changes beforehand. However, it builds only for the platform where it is executed, thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<I>Server CI</i>, if successful, should guarantee success when publishing, as it occurs in conditions similar to release workflow (all platforms, complete build environment). As a counterpart, it is generally significantly slower than local builds and also implies to commit and push changes beforehand, even if the code is in unstable state.<br />
<br />
The recommended workflow thus strives to make the most of all stages:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
<br />
flowchart TD;<br />
<br />
fork(Fork Source repository in your own Github space)<br />
clone("Clone your fork locally</br><code>git clone...</code>")<br />
devel(Make modifications in your local fork)<br />
localBuild("<b>Run local plain build</b></br><code>cmake</code>, <code>make</code>...")<br />
localCI("<b>Run local CI</b></br><code>act</code>")<br />
git("Commit, Rebase & Push</br><code>git ...</code>")<br />
serverCI(<b>Run server CI</b></br><code>Github workflow</code>)<br />
PR(PR your changes to Source repository)<br />
<br />
fork-->clone<br />
clone-->devel<br />
devel-->localBuild<br />
localBuild-->localCI<br />
localCI-- "<i>Success</br>(including debug & tests)</i>" -->git<br />
git-->serverCI<br />
serverCI-- <i>Success</i> -->PR<br />
<br />
localBuild & localCI & serverCI ----> |<i>Failure</i>| devel<br />
<br />
classDef BUILD fill:#acc,stroke-width:4px;<br />
class localBuild BUILD;<br />
class localCI BUILD;<br />
class serverCI BUILD;<br />
<br />
}}<br />
<br />
This is the common process between all components. Each step will then be adapted to each component, as explained below.<br />
<br />
Comments:<br />
* Running local CI relies on [https://github.com/nektos/act <code>nektos/act</code>]<br />
* Rebase must be made against upstream directory (<code>git pull --rebase upstream <branch></code>)before pushing<br />
* Push must be made towards developer own fork. Caveat: do not try to push directly to upstream<br />
<br />
<br />
== Build External Dependencies ==<br />
<br />
=== Local Plain Build ===<br />
==== Caveats ====<br />
Dependency local plain build is possible but:<br />
* Local plain build IS NOT THE RECOMMENDED BUILD for final deps. This build is solely intended for intermediary development and debugging. No support will be provided when used out-of-scope.<br />
* Local plain build has only be tested on Linux, with gcc >=14. For other platforms, adaptations should be necessary (contributions welcome). <br />
* Local plain build is much impacted by local particulars (local compiler version, dependencies already in cache or in system dirs etc.) and therefore does not guarantee further success for other (recommended) builds.<br />
<br />
==== Prerequisites ====<br />
In addition with general [[#Prerequisites_2 | Prerequisites]], you'll need the OneAPI ISPC compiler.<br />
<br />
==== Conan cache interaction ====<br />
<br />
The build relies on the local Conan cache, which will be modified by the process. You may want to make a copy beforehand.<br />
<br />
In some scenarios, you may also want to reset your Conan cache (warning: may remove files unrelated to LuxCoreDeps):<br />
<pre>conan remove -c "*" # Be careful: may remove packages unrelated to LuxCoreDeps!</pre><br />
<br />
==== Run ====<br />
<br />
To run a plain local build, run the following statements in a console, from the root of LuxCoreDeps repository:<br />
<br />
<pre><br />
export RUNNER_OS=<os><br />
export RUNNER_ARCH=<arch><br />
<br />
export LUXDEPS_VERSION=test<br />
export GCC_VERSION=14 # Note: even for gcc > 14<br />
export WORKSPACE=.<br />
export CXX_VERSION=20<br />
export CMAKE_POLICY_VERSION_MINIMUM=3.25<br />
export DEPS_BUILD_TYPE=Release # Or Debug/RelWithDebInfo/MinSizeRel, as needed<br />
export cache_dir<br />
<br />
./run_conan.sh<br />
</pre><br />
<br />
with <code>RUNNER_OS</code>, <code>RUNNER_ARCH</code> in:<br />
* <code>Linux</code> / <code>X64</code><br />
* <code>Windows</code> / <code>X64</code><br />
* <code>macOS</code> / <code>X64</code><br />
* <code>macOS</code> / <code>ARM64</code><br />
reflecting your build platform.<br />
<br />
No detection is made (compiler, OS, arch...) . You'll have to do it on your own and set environment variables accordingly.<br />
<br />
==== Cleaning ====<br />
<br />
Conan will produce a bunch of scripts in the root of LuxCoreDeps repo. You can clean them with the following:<br />
<pre> ./utils/clean-conan-files.sh </pre><br />
<br />
=== Local Continuous Integration ===<br />
<br />
Run <code>act</code> on workflows located in <code>.github/workflows</code> folder, for instance <code>.github/workflows/build.yml</code> workflow.</br><br />
<br />
For more convenience, a wrapper script is also provided in <code>LuxCoreDeps</code> repository (Linux only, at the moment): <pre>./utils/local-CI-build.sh</pre><br />
<br />
=== Server Continuous Integration ===<br />
<br />
This process relies on the following Github workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/checker.yml <code>LuxCore Dependency Checker</code>].<br />
</br>Important points:<br />
* Your changes must have been committed and pushed to repository before.<br />
* The Checker workflow is actually also triggered on push event, so you may not have to run it by yourself<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
== Build LuxCore, Samples & Python Wheels ==<br />
<br />
=== Local Plain Build ===<br />
<br />
==== Prerequisites ====<br />
<br />
First, we will assume you have correctly completed the [[#Prerequisites_2 | Prerequisites]]. <br />
<br />
Second, we will also assume you've already git-cloned LuxCore on your local machine, opened a terminal, changed directory to LuxCore folder and git-checked out the branch that you want to build (+ for Windows: initialized build environment with <code>vcvarsall.bat</code>)<br />
<br />
==== Basic build ====<br />
<br />
Our build system internally relies on <code>cmake</code> but, for more convenience, everything has been wrapped into <code>make</code>-like statements.<br />
<br />
So, to build LuxCore, one just have to enter the following magic words:<br />
<pre><br />
make deps<br />
make<br />
</pre><br />
<br />
This should retrieve and install LuxCore dependencies, configure the project and run the build. That's all!<br />
<br />
<br />
For subsequent builds, if no modification have been made to dependencies, you'll just have to re-enter: <pre>make</pre><br />
<br />
==== Specific targets ====<br />
<br />
If you want to target a specific component, you can replace the above plain <code>make</code> by one of the following verbs:<br />
<pre>make luxcore</pre><br />
<pre>make pyluxcore</pre><br />
<pre>make luxcoreui</pre><br />
<pre>make luxcoreconsole</pre><br />
<br />
<br />
Starting from version 2.11, this method can build a "test wheel". This is a simplified wheel, only for current platform and current Python version, for testing purpose. The test wheel is particularly useful for developing/debugging LuxCore/BlendLuxCore integration.<br />
The verb is:<br />
<pre>make wheel-test</pre><br />
<br />
<br />
You can also build Doxygen documentation with the following statement:<br />
<pre>make doc</pre><br />
<br />
==== Build type ====<br />
<br />
By default, this method builds a release version, striped from all symbols. If you want to build a debug version, enter the following before any <code>make ...</code> command:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug</pre> <br />
<br />
==== Local dependency set ====<br />
<br />
It is possible to use a local dependency set, rather than relying on automatic downloading. It is especially useful for developing/debugging of LuxCoreDeps/LuxCore integration. In this case, one can replace the <code>make deps</code> statement by the following one:<br />
<br />
<pre><br />
python -m build-system.luxmake.deps --local <path/to/local/deps> --release <release><br />
</pre><br />
<br />
Nota: <code><release></code> is the release tag used by your local dependency set. If you build this set locally, it should likely be <code>test</code>.<br />
<br />
==== Cleaning ====<br />
<br />
You can remove build outputs with one of the following statement:<br />
<pre>make clean</pre><br />
or<br />
<pre>make clear</pre><br />
The former will remove build files, however preserving dependencies. <br />
The latter will remove everything and will require to reinstall dependencies (<code>make deps</code>).<br />
<br />
=== Local Continuous Integration ===<br />
<br />
This method is complementary to Local plain build, with the following additional capabilities:<br />
* test the LuxCore build in an environment close to the release environment (manylinux container, for instance)<br />
* can build wheels<br />
* debug any changes made to the build workflow<br />
<br />
It consists in running Github workflows locally, via <code>act</code>. Github workflows are located in <code>.github/workflows</code> folder.<br />
<br />
<code>act</code> invokation can be made on command line but, for convenience, a wrapper script is provided (for Linux): <pre>./build-helpers/debug/debug_wheels.sh</pre><br />
<br />
<i>Caveat: this build can produce wheels, but only for the host platform (no cross-compiling).</i><br />
<br />
=== Server Continuous Integration ===<br />
<br />
The process is nearly the same as publisher build, but the release steps are skipped. For that purpose, another Github workflow has to be executed: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-builder.yml <code>LuxCore Python Wheels Builder</code>].<br />
<br />
Please note that your changes must have been committed to repository before running the workflow.<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
= Publisher Workflows =<br />
<br />
== Prerequisites ==<br />
<br />
For these workflows, a Github account is required, with extended rights on the source repositories.<br />
<br />
== General Workflow ==<br />
<br />
The general workflow for publishing is in 3 parts:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
flowchart TD;<br />
subgraph Build["<center><b>BUILD & RELEASE DRAFT </br>(Run Releaser workflow)</b></center>"]<br />
padBuild(" "):::INVISIBLE<br />
repo("Go to <code>[Source repository]</code> on Github and open <code>Actions menu</code>")<br />
select("Select <code>[Releaser workflow]</code>")<br />
runwf(Click on <code>Run workflow</code> button, in the upper-right corner)<br />
branch(Select <code>Branch</code> in drop-down menu)<br />
options(Set workflow options)<br />
validate(Click <code>Run workflow</code>)<br />
wait(Wait for build to complete)<br />
end<br />
<br />
subgraph Release["<center><b>MAKE FINAL RELEASE</br>(Switch release to final status)</b></center>"]<br />
padRelease(" "):::INVISIBLE<br />
release("Open <code>[Release folder]</code>,</br> find the newly-built release (in Draft mode) </br> and edit it")<br />
complete(Add relevant information: change log, comments on version etc.)<br />
dedraft(Unset <code>Draft</code> checkbox)<br />
update(Click <code>Publish release</code>/<code>Update release</code> to finalize)<br />
end<br />
<br />
subgraph Deploy["<center><b>PUBLISH</br>(Run Publisher workflow)</b></center>"]<br />
padDeploy(" ")<br />
repoDeploy("Go to <code>[Source repository]</code> on Github and open <code>[Actions menu]</code>")<br />
selectDeploy("Select <code>[Publisher workflow]</code>")<br />
runwfDeploy("Click on <code>Run workflow</code> drop-down button, in the upper-right corner")<br />
choiceDeploy("Select <code>Branch</code>, set the <code>Tag to publish</code> and uncheck <code>Publish on Pypi Test</code> if needed")<br />
validateDeploy("Click on <code>Run workflow</code> button")<br />
waitDeploy("Wait for deployment to complete")<br />
end<br />
<br />
padBuild---repo<br />
repo-->select<br />
select-->runwf<br />
runwf-->branch<br />
branch-->options<br />
options-->validate<br />
validate-->wait:::WAIT<br />
linkStyle 0 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padRelease---release<br />
release-->complete<br />
complete-->dedraft<br />
dedraft-->update<br />
linkStyle 7 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padDeploy:::INVISIBLE---repoDeploy<br />
repoDeploy-->selectDeploy<br />
selectDeploy-->runwfDeploy<br />
runwfDeploy-->choiceDeploy<br />
choiceDeploy-->validateDeploy<br />
validateDeploy-->waitDeploy:::WAIT<br />
linkStyle 11 stroke:#fff,color:blue,stroke-width:0px;<br />
<br />
<br />
Build-- <i>if success</i> -->Release<br />
Release-- <i>if success & if needed</i> -->Deploy<br />
<br />
classDef WAIT fill:#ddd;<br />
classDef DEPS fill:#e4d8ff,stroke:#9488af;<br />
classDef INVISIBLE fill:#ffffffff,stroke:#ffffffff,stroke-width:0px,font-color:#ffffffff;<br />
classDef OPTIONAL stroke-dasharray: 5 5;<br />
<br />
class Deploy OPTIONAL;<br />
<br />
%% Note: padXXX is a poor hack to create a top-margin in subgraph...<br />
}}<br />
<br />
A few comments:<br />
* <code>[bracketed tokens]</code> refer to data specific to each component, which will be detailed below.<br />
* Publish part is optional, it will depends on the target<br />
* ''Caveat: if you provide an already-existing release version number during the process, the workflow will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.''<br />
<br />
== Per-target details ==<br />
<br />
=== External Dependencies ===<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreRender/LuxCoreDeps</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/release.yml <code>LuxCore Dependency Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCoreDeps/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
As a byproduct, External Dependencies are not intended to be deployed, so no Publisher workflow is provided.<br />
<br />
=== Python Wheels ===<br />
<br />
<br />
<br />
As far as wheels are concerned, in addition to building them, it is also necessary to upload them to [https://pypi.org/ PyPi] ("publish" them), so that they are available for [https://pypi.org/project/pip pip] installation.<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-releaser.yml <code>LuxCore Wheels Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-publisher.yml <code>LuxCore Wheels Publisher</code>]<br />
<br />
''Prerequisite: you must have released a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.''<br />
<br />
=== Samples ===<br />
<br />
As we plan to replace Samples by equivalent Python tools and thus deprecate them, the workflow has been limited to the Release part (no publish).<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/sample-releaser.yml <code>LuxCore Samples Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
=== BlendLuxCore ===<br />
<br />
<i>TODO</i><br />
<br />
= Version Management =<br />
<br />
== Semantic Versioning ==<br />
<br />
Starting for LuxCore version 2.10.0, we require that LuxCoreRender applies [https://semver.org/ Semantic Versioning]. Please strictly enforce this rule when incrementing version numbers.<br />
<br />
Remark: component versions does not have to be synced. For instance, in strict application of the standard, the newly created LuxCoreDeps will start at 1.0.0, while at the same time LuxCore is already at 2.10.0<br />
<br />
== Dependency Version pointer ==<br />
<br />
To make LuxCore know which version of dependencies it must be built against, we use a pointer.<br />
<br />
This pointer is stored in the file <code>build-helpers/build-settings.json</code>, under the path <code>Dependencies/release</code>.<br />
<br />
Make sure you keep it up-to-date when you upgrade LuxCore components.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender&diff=2683Building LuxCoreRender2026-04-24T04:19:15Z<p>Howetuft: /* Run */</p>
<hr />
<div>This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.<br />
<br />
LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all [[Building_LuxCoreRender_(legacy)|previous documents]] related to the compilation of older versions (<=2.9).<br />
<br />
<br />
<b>TL;DR</b> If you are just interested in a quick, local (but platform limited) compilation of LuxCore C++ samples or Python wheels, you may want to jump directly to [[#Build LuxCore, Samples & Python Wheels | Build LuxCore, Samples & Python Wheels]].</br><br />
<br />
<br />
<br />
= Audience =<br />
<br />
This document is intended for:<br />
* LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;<br />
* Developers wishing to contribute to the project;<br />
* External package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;<br />
<br />
This document assumes that the reader is skilled in the following areas:<br />
* C/C++ compilation<br />
* [https://cmake.org/ cmake]<br />
* [https://git-scm.com/ git]<br />
* [https://docs.github.com/en/actions/writing-workflows Github Workflows]<br />
* [https://packaging.python.org/en/latest/ Python Packaging], including [https://realpython.com/python-wheels/ Python Wheels format]<br />
<br />
Familiarity with [https://conan.io/ Conan] dependency manager may also help.<br />
<br />
</br><br />
This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries on the official [https://luxcorerender.org/download/ Download] page.<br />
<br />
= Build Targets =<br />
<br />
== Synoptic ==<br />
LuxCoreRender contains several build targets, below represented with dependency links:<br />
<br />
{{#mermaid:<br />
%%{<br />
init: {<br />
"theme": "forest",<br />
"logLevel": "info",<br />
"flowchart": {"curve": "basis"}<br />
}<br />
}%%<br />
<br />
flowchart LR;<br />
<br />
<br />
classDef TYPE font-weight:bold,font-size:1.1rem;<br />
classDef TARGET font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCOREDEPS fill:#ffe8ff,stroke:#9488af,font-weight:bold,font-size:1.1rem;<br />
classDef TARGETDEPS fill:#e4d8ff,stroke:#9488af,font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCORE fill:#bbceff,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETLUXCORE fill:#7799ee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef SAMPLES fill:#ffffdd,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETSAMPLES fill:#eeeecc,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef NEUTRAL fill:#fafafa,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETNEUTRAL fill:#eeeeee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef EXTDEP fill:#00000000,stroke:#00000000;<br />
<br />
<br />
subgraph Dependencies[External Dependencies]<br />
deps(LuxCore Dependencies)<br />
end<br />
<br />
class Dependencies LUXCOREDEPS;<br />
class deps TARGETDEPS;<br />
<br />
<br />
subgraph LuxCore<br />
lux(luxcore.so/.dll)<br />
luxa(luxcore.a)<br />
end<br />
class LuxCore LUXCORE;<br />
class lux TARGETLUXCORE;<br />
class luxa TARGETLUXCORE;<br />
<br />
subgraph Python_Wheels[Python Wheels]<br />
pylux(pyluxcore.so/.dll)<br />
wheels(LuxCore Python Wheels)<br />
end<br />
class Python_Wheels TYPE;<br />
class pylux TARGET;<br />
class wheels TARGET;<br />
<br />
subgraph Samples<br />
luxcoreui(luxcoreui)<br />
luxcoreconsole(luxcoreconsole)<br />
end<br />
class Samples SAMPLES;<br />
class luxcoreui TARGETSAMPLES;<br />
class luxcoreconsole TARGETSAMPLES;<br />
<br />
<br />
subgraph PyLuxCoreTools<br />
pyluxcon(pyluxcoreconsole)<br />
pyluxothers(...)<br />
end<br />
class PyLuxCoreTools NEUTRAL;<br />
class pyluxcon TARGETNEUTRAL;<br />
class pyluxothers TARGETNEUTRAL;<br />
<br />
subgraph Plugins[Python Plugins]<br />
blc(BlendLuxCore)<br />
otherplugins(...)<br />
end<br />
class blc TARGETNEUTRAL;<br />
class otherplugins TARGETNEUTRAL;<br />
<br />
class Plugins NEUTRAL;<br />
<br />
%% Warning: order matters<br />
deps-->lux<br />
deps-->luxa<br />
deps-->luxcoreui<br />
deps-->luxcoreconsole<br />
<br />
luxa--->pylux<br />
lux-->luxcoreui<br />
lux-->luxcoreconsole<br />
deps-->pylux<br />
<br />
<br />
<br />
pylux-->wheels<br />
wheels-. runtime .->blc<br />
wheels-. runtime .->otherplugins<br />
<br />
wheels-. runtime .->pyluxcon<br />
wheels-. runtime .->pyluxothers<br />
<br />
Python:::EXTDEP-->pylux<br />
<br />
<br />
%% Mermaid version: 8.14.0<br />
%% https://github.com/mermaid-js/mermaid/blob/8.14.0/src/defaultConfig.js<br />
<br />
<br />
<br />
}}<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! Target !! Source Repository !! Content<br />
|-<br />
| <b>External Dependencies</b>|| [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreDeps</code>] || A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to [https://github.com/LuxCoreRender/LuxCoreDeps/blob/main/README.md LuxCoreDeps README] for more information.<br />
|-<br />
| <b>LuxCore</b> || [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.<br />
|-<br />
| <b>Samples</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Sample C++ programs, illustrating luxcore use, namely <code>luxcoreconsole</code> and <code>luxcoreui</code><br />
|-<br />
| <b>Python Wheels</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version).</br> As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).<br />
|-<br />
| <b>Python Plugins</b>|| [https://github.com/LuxCoreRender/BlendLuxCore <code>BlendLuxCore</code>] etc. || Plugins to expose LuxCore in various external applications, notably Blender. </br> Written in Python and relying on Python Wheels as runtime dependency.<br />
|-<br />
| <b>PyLuxCoreTools</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python LuxCore Tools: set of command line tools based on pyluxcore, written in Python.<br />
|}<br />
<br />
== Targeted platforms ==<br />
<br />
LuxCoreRender aims at being available on the following 4 platforms:<br />
* Linux (glibc 2.28+)<br />
* Windows<br />
* MacOS Intel (>=10.15)<br />
* MacOS Arm (>=12.0)<br />
<br />
For Python-related targets, LuxCoreRender aims at being declined for [https://devguide.python.org/versions all Python versions supported at a given time].<br />
<br />
= Workflow Types =<br />
<br />
We distinguish between two types of build workflows:<br />
* Developer workflows<br />
* Publisher workflows<br />
<br />
<br />
''[[#Developer Workflows | Developer workflows]]'' are designed for development, debugging and test steps.<br />
<br />
Their purpose is to allow development and verify the code is ready for publication.<br />
<br />
<br />
''[[#Publisher Workflows | Publisher workflows]]'' are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.<br />
<br />
They exclusively take place in a CI/CD Github pipeline.<br />
<br />
These workflows are not designed for debugging or testing the underlying code. Execution of these workflows assumes that the development phase has been correctly completed and the underlying code is ready for final build and release. See [[#Developer Workflows | Developer Workflows]] to learn how to get code ready for final build.<br />
<br />
Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.<br />
<br />
= Developer Workflows =<br />
<br />
<br />
== Prerequisites ==<br />
<br />
<u>Tools</u><br />
<br />
You will need several build tools installed and referenced in the PATH.<br />
<br />
First, ensure you have a suitable toolchain:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! OS !! Compiler !! Minimal version<br />
|-<br />
| Windows || MSVC || 194x latest version<br />
|-<br />
| Linux|| gcc || 14<br />
|-<br />
| MacOS Intel|| XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|-<br />
| MacOS Arm || XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|}<br />
<br />
''Toolchain compliance is a very sensitive condition for a successful build. Before filing any claim, please check that your toolchain complies with the above requirements.''<br />
<br />
<br />
<br />
Then ensure the following software is also installed and available in your PATH:<br />
<br />
* [https://git-scm.com/ Git]<br />
* [https://cli.github.com/ Github CLI] (optional but recommended - for dependency signature checking)<br />
* [https://www.python.org/ Python 3] - any [https://devguide.python.org/versions/ currently supported version]<br />
* [https://conan.io Conan] latest version (pip install conan)<br />
* [https://github.com/pypa/wheel/tree/main Wheel] latest version (pip install wheel)<br />
* [https://cmake.org/ CMake] >= 3.29<br />
* [https://github.com/nektos/act nektos/act] (optional but recommended - for local build based on Github workflows)<br />
* [https://pypi.org/project/repairwheel repairwheel] (optional but recommended - for local build of test wheels)<br />
<br />
<br />
Platform specifics:<br />
* For Windows, ensure the command line is configured for building (<code>vcvarsall.bat</code>).<br />
* For Linux, you'll need <code>pkgconfig</code> in addition.<br />
* For MacOS, you'll need to ensure CC and CXX point to LLVM clang/clang++<br />
<br />
<u>Accounts</u><br />
<br />
A ''Github account'' is mandatory for LuxCore development.<br />
<br />
Following accounts are also recommended, in order to get in touch with LuxCore community:<br />
* [https://forums.luxcorerender.org/ LuxCoreRender Forums]<br />
* [https://discord.gg/chPGsKV LuxCoreRender Discord channel]<br />
<br />
== General Developer Workflow ==<br />
<br />
To compile and verify LuxCore component modifications in development process, there are 3 stages:<br />
* Local plain build: only run build system (cmake) on developer computer<br />
* Local Continuous Integration build: run full Continuous Integration workflow on developer computer<br />
* Server Continuous Integration build: run full Continuous Integration workflow on server<br />
<br />
<i>Local plain build</i> is generally faster than other builds and does not require to commit changes beforehand. Plain build installs a minimal build configuration (dependencies), but heavily relies on computer build environment for the rest (build tools, system libraries etc.). As a counterpart, it builds only for the platform where it is executed and can be significantly altered by local conditions (build tools local versions, dependency local versions etc.), thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<i>LocalCI </i> is generally faster than Server build, but slower than local plain build. CI workflow installs a complete build environment (compilers, sdk, build tools, containers, dependencies etc.) before running build system. It does not require to commit changes beforehand. However, it builds only for the platform where it is executed, thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<I>Server CI</i>, if successful, should guarantee success when publishing, as it occurs in conditions similar to release workflow (all platforms, complete build environment). As a counterpart, it is generally significantly slower than local builds and also implies to commit and push changes beforehand, even if the code is in unstable state.<br />
<br />
The recommended workflow thus strives to make the most of all stages:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
<br />
flowchart TD;<br />
<br />
fork(Fork Source repository in your own Github space)<br />
clone("Clone your fork locally</br><code>git clone...</code>")<br />
devel(Make modifications in your local fork)<br />
localBuild("<b>Run local plain build</b></br><code>cmake</code>, <code>make</code>...")<br />
localCI("<b>Run local CI</b></br><code>act</code>")<br />
git("Commit, Rebase & Push</br><code>git ...</code>")<br />
serverCI(<b>Run server CI</b></br><code>Github workflow</code>)<br />
PR(PR your changes to Source repository)<br />
<br />
fork-->clone<br />
clone-->devel<br />
devel-->localBuild<br />
localBuild-->localCI<br />
localCI-- "<i>Success</br>(including debug & tests)</i>" -->git<br />
git-->serverCI<br />
serverCI-- <i>Success</i> -->PR<br />
<br />
localBuild & localCI & serverCI ----> |<i>Failure</i>| devel<br />
<br />
classDef BUILD fill:#acc,stroke-width:4px;<br />
class localBuild BUILD;<br />
class localCI BUILD;<br />
class serverCI BUILD;<br />
<br />
}}<br />
<br />
This is the common process between all components. Each step will then be adapted to each component, as explained below.<br />
<br />
Comments:<br />
* Running local CI relies on [https://github.com/nektos/act <code>nektos/act</code>]<br />
* Rebase must be made against upstream directory (<code>git pull --rebase upstream <branch></code>)before pushing<br />
* Push must be made towards developer own fork. Caveat: do not try to push directly to upstream<br />
<br />
<br />
== Build External Dependencies ==<br />
<br />
=== Local Plain Build ===<br />
==== Caveats ====<br />
Dependency local plain build is possible but:<br />
* Local plain build IS NOT THE RECOMMENDED BUILD for final deps. This build is solely intended for intermediary development and debugging. No support will be provided when used out-of-scope.<br />
* Local plain build has only be tested on Linux, with gcc >=14. For other platforms, adaptations should be necessary (contributions welcome). <br />
* Local plain build is much impacted by local particulars (local compiler version, dependencies already in cache or in system dirs etc.) and therefore does not guarantee further success for other (recommended) builds.<br />
<br />
==== Prerequisites ====<br />
In addition with general [[#Prerequisites_2 | Prerequisites]], you'll need the OneAPI ISPC compiler.<br />
<br />
==== Conan cache interaction ====<br />
<br />
The build relies on the local Conan cache, which will be modified by the process. You may want to make a copy beforehand.<br />
<br />
In some scenarios, you may also want to reset your Conan cache (warning: may remove files unrelated to LuxCoreDeps):<br />
<pre>conan remove -c "*" # Be careful: may remove packages unrelated to LuxCoreDeps!</pre><br />
<br />
==== Run ====<br />
<br />
To run a plain local build, run the following statements in a console, from the root of LuxCoreDeps repository:<br />
<br />
<pre><br />
export RUNNER_OS=<os><br />
export RUNNER_ARCH=<arch><br />
<br />
export LUXDEPS_VERSION=test<br />
export GCC_VERSION=14 # Note: even for gcc > 14<br />
export WORKSPACE=.<br />
export CXX_VERSION=20<br />
export CMAKE_POLICY_VERSION_MINIMUM=3.25<br />
export DEPS_BUILD_TYPE=Release # Or Debug/RelWithDebInfo/MinSizeRel, if needed<br />
export cache_dir<br />
<br />
./run_conan.sh<br />
</pre><br />
<br />
with <code>RUNNER_OS</code>, <code>RUNNER_ARCH</code> in:<br />
* <code>Linux</code> / <code>X64</code><br />
* <code>Windows</code> / <code>X64</code><br />
* <code>macOS</code> / <code>X64</code><br />
* <code>macOS</code> / <code>ARM64</code><br />
reflecting your build platform.<br />
<br />
No detection is made (compiler, OS, arch...) . You'll have to do it on your own and set environment variables accordingly.<br />
<br />
==== Cleaning ====<br />
<br />
Conan will produce a bunch of scripts in the root of LuxCoreDeps repo. You can clean them with the following:<br />
<pre> ./utils/clean-conan-files.sh </pre><br />
<br />
=== Local Continuous Integration ===<br />
<br />
Run <code>act</code> on workflows located in <code>.github/workflows</code> folder, for instance <code>.github/workflows/build.yml</code> workflow.</br><br />
<br />
For more convenience, a wrapper script is also provided in <code>LuxCoreDeps</code> repository (Linux only, at the moment): <pre>./utils/local-CI-build.sh</pre><br />
<br />
=== Server Continuous Integration ===<br />
<br />
This process relies on the following Github workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/checker.yml <code>LuxCore Dependency Checker</code>].<br />
</br>Important points:<br />
* Your changes must have been committed and pushed to repository before.<br />
* The Checker workflow is actually also triggered on push event, so you may not have to run it by yourself<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
== Build LuxCore, Samples & Python Wheels ==<br />
<br />
=== Local Plain Build ===<br />
<br />
==== Prerequisites ====<br />
<br />
First, we will assume you have correctly completed the [[#Prerequisites_2 | Prerequisites]]. <br />
<br />
Second, we will also assume you've already git-cloned LuxCore on your local machine, opened a terminal, changed directory to LuxCore folder and git-checked out the branch that you want to build (+ for Windows: initialized build environment with <code>vcvarsall.bat</code>)<br />
<br />
==== Basic build ====<br />
<br />
Our build system internally relies on <code>cmake</code> but, for more convenience, everything has been wrapped into <code>make</code>-like statements.<br />
<br />
So, to build LuxCore, one just have to enter the following magic words:<br />
<pre><br />
make deps<br />
make<br />
</pre><br />
<br />
This should retrieve and install LuxCore dependencies, configure the project and run the build. That's all!<br />
<br />
<br />
For subsequent builds, if no modification have been made to dependencies, you'll just have to re-enter: <pre>make</pre><br />
<br />
==== Specific targets ====<br />
<br />
If you want to target a specific component, you can replace the above plain <code>make</code> by one of the following verbs:<br />
<pre>make luxcore</pre><br />
<pre>make pyluxcore</pre><br />
<pre>make luxcoreui</pre><br />
<pre>make luxcoreconsole</pre><br />
<br />
<br />
Starting from version 2.11, this method can build a "test wheel". This is a simplified wheel, only for current platform and current Python version, for testing purpose. The test wheel is particularly useful for developing/debugging LuxCore/BlendLuxCore integration.<br />
The verb is:<br />
<pre>make wheel-test</pre><br />
<br />
<br />
You can also build Doxygen documentation with the following statement:<br />
<pre>make doc</pre><br />
<br />
==== Build type ====<br />
<br />
By default, this method builds a release version, striped from all symbols. If you want to build a debug version, enter the following before any <code>make ...</code> command:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug</pre> <br />
<br />
==== Local dependency set ====<br />
<br />
It is possible to use a local dependency set, rather than relying on automatic downloading. It is especially useful for developing/debugging of LuxCoreDeps/LuxCore integration. In this case, one can replace the <code>make deps</code> statement by the following one:<br />
<br />
<pre><br />
python -m build-system.luxmake.deps --local <path/to/local/deps> --release <release><br />
</pre><br />
<br />
Nota: <code><release></code> is the release tag used by your local dependency set. If you build this set locally, it should likely be <code>test</code>.<br />
<br />
==== Cleaning ====<br />
<br />
You can remove build outputs with one of the following statement:<br />
<pre>make clean</pre><br />
or<br />
<pre>make clear</pre><br />
The former will remove build files, however preserving dependencies. <br />
The latter will remove everything and will require to reinstall dependencies (<code>make deps</code>).<br />
<br />
=== Local Continuous Integration ===<br />
<br />
This method is complementary to Local plain build, with the following additional capabilities:<br />
* test the LuxCore build in an environment close to the release environment (manylinux container, for instance)<br />
* can build wheels<br />
* debug any changes made to the build workflow<br />
<br />
It consists in running Github workflows locally, via <code>act</code>. Github workflows are located in <code>.github/workflows</code> folder.<br />
<br />
<code>act</code> invokation can be made on command line but, for convenience, a wrapper script is provided (for Linux): <pre>./build-helpers/debug/debug_wheels.sh</pre><br />
<br />
<i>Caveat: this build can produce wheels, but only for the host platform (no cross-compiling).</i><br />
<br />
=== Server Continuous Integration ===<br />
<br />
The process is nearly the same as publisher build, but the release steps are skipped. For that purpose, another Github workflow has to be executed: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-builder.yml <code>LuxCore Python Wheels Builder</code>].<br />
<br />
Please note that your changes must have been committed to repository before running the workflow.<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
= Publisher Workflows =<br />
<br />
== Prerequisites ==<br />
<br />
For these workflows, a Github account is required, with extended rights on the source repositories.<br />
<br />
== General Workflow ==<br />
<br />
The general workflow for publishing is in 3 parts:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
flowchart TD;<br />
subgraph Build["<center><b>BUILD & RELEASE DRAFT </br>(Run Releaser workflow)</b></center>"]<br />
padBuild(" "):::INVISIBLE<br />
repo("Go to <code>[Source repository]</code> on Github and open <code>Actions menu</code>")<br />
select("Select <code>[Releaser workflow]</code>")<br />
runwf(Click on <code>Run workflow</code> button, in the upper-right corner)<br />
branch(Select <code>Branch</code> in drop-down menu)<br />
options(Set workflow options)<br />
validate(Click <code>Run workflow</code>)<br />
wait(Wait for build to complete)<br />
end<br />
<br />
subgraph Release["<center><b>MAKE FINAL RELEASE</br>(Switch release to final status)</b></center>"]<br />
padRelease(" "):::INVISIBLE<br />
release("Open <code>[Release folder]</code>,</br> find the newly-built release (in Draft mode) </br> and edit it")<br />
complete(Add relevant information: change log, comments on version etc.)<br />
dedraft(Unset <code>Draft</code> checkbox)<br />
update(Click <code>Publish release</code>/<code>Update release</code> to finalize)<br />
end<br />
<br />
subgraph Deploy["<center><b>PUBLISH</br>(Run Publisher workflow)</b></center>"]<br />
padDeploy(" ")<br />
repoDeploy("Go to <code>[Source repository]</code> on Github and open <code>[Actions menu]</code>")<br />
selectDeploy("Select <code>[Publisher workflow]</code>")<br />
runwfDeploy("Click on <code>Run workflow</code> drop-down button, in the upper-right corner")<br />
choiceDeploy("Select <code>Branch</code>, set the <code>Tag to publish</code> and uncheck <code>Publish on Pypi Test</code> if needed")<br />
validateDeploy("Click on <code>Run workflow</code> button")<br />
waitDeploy("Wait for deployment to complete")<br />
end<br />
<br />
padBuild---repo<br />
repo-->select<br />
select-->runwf<br />
runwf-->branch<br />
branch-->options<br />
options-->validate<br />
validate-->wait:::WAIT<br />
linkStyle 0 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padRelease---release<br />
release-->complete<br />
complete-->dedraft<br />
dedraft-->update<br />
linkStyle 7 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padDeploy:::INVISIBLE---repoDeploy<br />
repoDeploy-->selectDeploy<br />
selectDeploy-->runwfDeploy<br />
runwfDeploy-->choiceDeploy<br />
choiceDeploy-->validateDeploy<br />
validateDeploy-->waitDeploy:::WAIT<br />
linkStyle 11 stroke:#fff,color:blue,stroke-width:0px;<br />
<br />
<br />
Build-- <i>if success</i> -->Release<br />
Release-- <i>if success & if needed</i> -->Deploy<br />
<br />
classDef WAIT fill:#ddd;<br />
classDef DEPS fill:#e4d8ff,stroke:#9488af;<br />
classDef INVISIBLE fill:#ffffffff,stroke:#ffffffff,stroke-width:0px,font-color:#ffffffff;<br />
classDef OPTIONAL stroke-dasharray: 5 5;<br />
<br />
class Deploy OPTIONAL;<br />
<br />
%% Note: padXXX is a poor hack to create a top-margin in subgraph...<br />
}}<br />
<br />
A few comments:<br />
* <code>[bracketed tokens]</code> refer to data specific to each component, which will be detailed below.<br />
* Publish part is optional, it will depends on the target<br />
* ''Caveat: if you provide an already-existing release version number during the process, the workflow will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.''<br />
<br />
== Per-target details ==<br />
<br />
=== External Dependencies ===<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreRender/LuxCoreDeps</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/release.yml <code>LuxCore Dependency Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCoreDeps/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
As a byproduct, External Dependencies are not intended to be deployed, so no Publisher workflow is provided.<br />
<br />
=== Python Wheels ===<br />
<br />
<br />
<br />
As far as wheels are concerned, in addition to building them, it is also necessary to upload them to [https://pypi.org/ PyPi] ("publish" them), so that they are available for [https://pypi.org/project/pip pip] installation.<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-releaser.yml <code>LuxCore Wheels Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-publisher.yml <code>LuxCore Wheels Publisher</code>]<br />
<br />
''Prerequisite: you must have released a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.''<br />
<br />
=== Samples ===<br />
<br />
As we plan to replace Samples by equivalent Python tools and thus deprecate them, the workflow has been limited to the Release part (no publish).<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/sample-releaser.yml <code>LuxCore Samples Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
=== BlendLuxCore ===<br />
<br />
<i>TODO</i><br />
<br />
= Version Management =<br />
<br />
== Semantic Versioning ==<br />
<br />
Starting for LuxCore version 2.10.0, we require that LuxCoreRender applies [https://semver.org/ Semantic Versioning]. Please strictly enforce this rule when incrementing version numbers.<br />
<br />
Remark: component versions does not have to be synced. For instance, in strict application of the standard, the newly created LuxCoreDeps will start at 1.0.0, while at the same time LuxCore is already at 2.10.0<br />
<br />
== Dependency Version pointer ==<br />
<br />
To make LuxCore know which version of dependencies it must be built against, we use a pointer.<br />
<br />
This pointer is stored in the file <code>build-helpers/build-settings.json</code>, under the path <code>Dependencies/release</code>.<br />
<br />
Make sure you keep it up-to-date when you upgrade LuxCore components.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender&diff=2682Building LuxCoreRender2026-04-24T04:18:51Z<p>Howetuft: /* Run */</p>
<hr />
<div>This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.<br />
<br />
LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all [[Building_LuxCoreRender_(legacy)|previous documents]] related to the compilation of older versions (<=2.9).<br />
<br />
<br />
<b>TL;DR</b> If you are just interested in a quick, local (but platform limited) compilation of LuxCore C++ samples or Python wheels, you may want to jump directly to [[#Build LuxCore, Samples & Python Wheels | Build LuxCore, Samples & Python Wheels]].</br><br />
<br />
<br />
<br />
= Audience =<br />
<br />
This document is intended for:<br />
* LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;<br />
* Developers wishing to contribute to the project;<br />
* External package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;<br />
<br />
This document assumes that the reader is skilled in the following areas:<br />
* C/C++ compilation<br />
* [https://cmake.org/ cmake]<br />
* [https://git-scm.com/ git]<br />
* [https://docs.github.com/en/actions/writing-workflows Github Workflows]<br />
* [https://packaging.python.org/en/latest/ Python Packaging], including [https://realpython.com/python-wheels/ Python Wheels format]<br />
<br />
Familiarity with [https://conan.io/ Conan] dependency manager may also help.<br />
<br />
</br><br />
This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries on the official [https://luxcorerender.org/download/ Download] page.<br />
<br />
= Build Targets =<br />
<br />
== Synoptic ==<br />
LuxCoreRender contains several build targets, below represented with dependency links:<br />
<br />
{{#mermaid:<br />
%%{<br />
init: {<br />
"theme": "forest",<br />
"logLevel": "info",<br />
"flowchart": {"curve": "basis"}<br />
}<br />
}%%<br />
<br />
flowchart LR;<br />
<br />
<br />
classDef TYPE font-weight:bold,font-size:1.1rem;<br />
classDef TARGET font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCOREDEPS fill:#ffe8ff,stroke:#9488af,font-weight:bold,font-size:1.1rem;<br />
classDef TARGETDEPS fill:#e4d8ff,stroke:#9488af,font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCORE fill:#bbceff,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETLUXCORE fill:#7799ee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef SAMPLES fill:#ffffdd,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETSAMPLES fill:#eeeecc,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef NEUTRAL fill:#fafafa,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETNEUTRAL fill:#eeeeee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef EXTDEP fill:#00000000,stroke:#00000000;<br />
<br />
<br />
subgraph Dependencies[External Dependencies]<br />
deps(LuxCore Dependencies)<br />
end<br />
<br />
class Dependencies LUXCOREDEPS;<br />
class deps TARGETDEPS;<br />
<br />
<br />
subgraph LuxCore<br />
lux(luxcore.so/.dll)<br />
luxa(luxcore.a)<br />
end<br />
class LuxCore LUXCORE;<br />
class lux TARGETLUXCORE;<br />
class luxa TARGETLUXCORE;<br />
<br />
subgraph Python_Wheels[Python Wheels]<br />
pylux(pyluxcore.so/.dll)<br />
wheels(LuxCore Python Wheels)<br />
end<br />
class Python_Wheels TYPE;<br />
class pylux TARGET;<br />
class wheels TARGET;<br />
<br />
subgraph Samples<br />
luxcoreui(luxcoreui)<br />
luxcoreconsole(luxcoreconsole)<br />
end<br />
class Samples SAMPLES;<br />
class luxcoreui TARGETSAMPLES;<br />
class luxcoreconsole TARGETSAMPLES;<br />
<br />
<br />
subgraph PyLuxCoreTools<br />
pyluxcon(pyluxcoreconsole)<br />
pyluxothers(...)<br />
end<br />
class PyLuxCoreTools NEUTRAL;<br />
class pyluxcon TARGETNEUTRAL;<br />
class pyluxothers TARGETNEUTRAL;<br />
<br />
subgraph Plugins[Python Plugins]<br />
blc(BlendLuxCore)<br />
otherplugins(...)<br />
end<br />
class blc TARGETNEUTRAL;<br />
class otherplugins TARGETNEUTRAL;<br />
<br />
class Plugins NEUTRAL;<br />
<br />
%% Warning: order matters<br />
deps-->lux<br />
deps-->luxa<br />
deps-->luxcoreui<br />
deps-->luxcoreconsole<br />
<br />
luxa--->pylux<br />
lux-->luxcoreui<br />
lux-->luxcoreconsole<br />
deps-->pylux<br />
<br />
<br />
<br />
pylux-->wheels<br />
wheels-. runtime .->blc<br />
wheels-. runtime .->otherplugins<br />
<br />
wheels-. runtime .->pyluxcon<br />
wheels-. runtime .->pyluxothers<br />
<br />
Python:::EXTDEP-->pylux<br />
<br />
<br />
%% Mermaid version: 8.14.0<br />
%% https://github.com/mermaid-js/mermaid/blob/8.14.0/src/defaultConfig.js<br />
<br />
<br />
<br />
}}<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! Target !! Source Repository !! Content<br />
|-<br />
| <b>External Dependencies</b>|| [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreDeps</code>] || A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to [https://github.com/LuxCoreRender/LuxCoreDeps/blob/main/README.md LuxCoreDeps README] for more information.<br />
|-<br />
| <b>LuxCore</b> || [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.<br />
|-<br />
| <b>Samples</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Sample C++ programs, illustrating luxcore use, namely <code>luxcoreconsole</code> and <code>luxcoreui</code><br />
|-<br />
| <b>Python Wheels</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version).</br> As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).<br />
|-<br />
| <b>Python Plugins</b>|| [https://github.com/LuxCoreRender/BlendLuxCore <code>BlendLuxCore</code>] etc. || Plugins to expose LuxCore in various external applications, notably Blender. </br> Written in Python and relying on Python Wheels as runtime dependency.<br />
|-<br />
| <b>PyLuxCoreTools</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python LuxCore Tools: set of command line tools based on pyluxcore, written in Python.<br />
|}<br />
<br />
== Targeted platforms ==<br />
<br />
LuxCoreRender aims at being available on the following 4 platforms:<br />
* Linux (glibc 2.28+)<br />
* Windows<br />
* MacOS Intel (>=10.15)<br />
* MacOS Arm (>=12.0)<br />
<br />
For Python-related targets, LuxCoreRender aims at being declined for [https://devguide.python.org/versions all Python versions supported at a given time].<br />
<br />
= Workflow Types =<br />
<br />
We distinguish between two types of build workflows:<br />
* Developer workflows<br />
* Publisher workflows<br />
<br />
<br />
''[[#Developer Workflows | Developer workflows]]'' are designed for development, debugging and test steps.<br />
<br />
Their purpose is to allow development and verify the code is ready for publication.<br />
<br />
<br />
''[[#Publisher Workflows | Publisher workflows]]'' are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.<br />
<br />
They exclusively take place in a CI/CD Github pipeline.<br />
<br />
These workflows are not designed for debugging or testing the underlying code. Execution of these workflows assumes that the development phase has been correctly completed and the underlying code is ready for final build and release. See [[#Developer Workflows | Developer Workflows]] to learn how to get code ready for final build.<br />
<br />
Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.<br />
<br />
= Developer Workflows =<br />
<br />
<br />
== Prerequisites ==<br />
<br />
<u>Tools</u><br />
<br />
You will need several build tools installed and referenced in the PATH.<br />
<br />
First, ensure you have a suitable toolchain:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! OS !! Compiler !! Minimal version<br />
|-<br />
| Windows || MSVC || 194x latest version<br />
|-<br />
| Linux|| gcc || 14<br />
|-<br />
| MacOS Intel|| XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|-<br />
| MacOS Arm || XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|}<br />
<br />
''Toolchain compliance is a very sensitive condition for a successful build. Before filing any claim, please check that your toolchain complies with the above requirements.''<br />
<br />
<br />
<br />
Then ensure the following software is also installed and available in your PATH:<br />
<br />
* [https://git-scm.com/ Git]<br />
* [https://cli.github.com/ Github CLI] (optional but recommended - for dependency signature checking)<br />
* [https://www.python.org/ Python 3] - any [https://devguide.python.org/versions/ currently supported version]<br />
* [https://conan.io Conan] latest version (pip install conan)<br />
* [https://github.com/pypa/wheel/tree/main Wheel] latest version (pip install wheel)<br />
* [https://cmake.org/ CMake] >= 3.29<br />
* [https://github.com/nektos/act nektos/act] (optional but recommended - for local build based on Github workflows)<br />
* [https://pypi.org/project/repairwheel repairwheel] (optional but recommended - for local build of test wheels)<br />
<br />
<br />
Platform specifics:<br />
* For Windows, ensure the command line is configured for building (<code>vcvarsall.bat</code>).<br />
* For Linux, you'll need <code>pkgconfig</code> in addition.<br />
* For MacOS, you'll need to ensure CC and CXX point to LLVM clang/clang++<br />
<br />
<u>Accounts</u><br />
<br />
A ''Github account'' is mandatory for LuxCore development.<br />
<br />
Following accounts are also recommended, in order to get in touch with LuxCore community:<br />
* [https://forums.luxcorerender.org/ LuxCoreRender Forums]<br />
* [https://discord.gg/chPGsKV LuxCoreRender Discord channel]<br />
<br />
== General Developer Workflow ==<br />
<br />
To compile and verify LuxCore component modifications in development process, there are 3 stages:<br />
* Local plain build: only run build system (cmake) on developer computer<br />
* Local Continuous Integration build: run full Continuous Integration workflow on developer computer<br />
* Server Continuous Integration build: run full Continuous Integration workflow on server<br />
<br />
<i>Local plain build</i> is generally faster than other builds and does not require to commit changes beforehand. Plain build installs a minimal build configuration (dependencies), but heavily relies on computer build environment for the rest (build tools, system libraries etc.). As a counterpart, it builds only for the platform where it is executed and can be significantly altered by local conditions (build tools local versions, dependency local versions etc.), thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<i>LocalCI </i> is generally faster than Server build, but slower than local plain build. CI workflow installs a complete build environment (compilers, sdk, build tools, containers, dependencies etc.) before running build system. It does not require to commit changes beforehand. However, it builds only for the platform where it is executed, thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<I>Server CI</i>, if successful, should guarantee success when publishing, as it occurs in conditions similar to release workflow (all platforms, complete build environment). As a counterpart, it is generally significantly slower than local builds and also implies to commit and push changes beforehand, even if the code is in unstable state.<br />
<br />
The recommended workflow thus strives to make the most of all stages:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
<br />
flowchart TD;<br />
<br />
fork(Fork Source repository in your own Github space)<br />
clone("Clone your fork locally</br><code>git clone...</code>")<br />
devel(Make modifications in your local fork)<br />
localBuild("<b>Run local plain build</b></br><code>cmake</code>, <code>make</code>...")<br />
localCI("<b>Run local CI</b></br><code>act</code>")<br />
git("Commit, Rebase & Push</br><code>git ...</code>")<br />
serverCI(<b>Run server CI</b></br><code>Github workflow</code>)<br />
PR(PR your changes to Source repository)<br />
<br />
fork-->clone<br />
clone-->devel<br />
devel-->localBuild<br />
localBuild-->localCI<br />
localCI-- "<i>Success</br>(including debug & tests)</i>" -->git<br />
git-->serverCI<br />
serverCI-- <i>Success</i> -->PR<br />
<br />
localBuild & localCI & serverCI ----> |<i>Failure</i>| devel<br />
<br />
classDef BUILD fill:#acc,stroke-width:4px;<br />
class localBuild BUILD;<br />
class localCI BUILD;<br />
class serverCI BUILD;<br />
<br />
}}<br />
<br />
This is the common process between all components. Each step will then be adapted to each component, as explained below.<br />
<br />
Comments:<br />
* Running local CI relies on [https://github.com/nektos/act <code>nektos/act</code>]<br />
* Rebase must be made against upstream directory (<code>git pull --rebase upstream <branch></code>)before pushing<br />
* Push must be made towards developer own fork. Caveat: do not try to push directly to upstream<br />
<br />
<br />
== Build External Dependencies ==<br />
<br />
=== Local Plain Build ===<br />
==== Caveats ====<br />
Dependency local plain build is possible but:<br />
* Local plain build IS NOT THE RECOMMENDED BUILD for final deps. This build is solely intended for intermediary development and debugging. No support will be provided when used out-of-scope.<br />
* Local plain build has only be tested on Linux, with gcc >=14. For other platforms, adaptations should be necessary (contributions welcome). <br />
* Local plain build is much impacted by local particulars (local compiler version, dependencies already in cache or in system dirs etc.) and therefore does not guarantee further success for other (recommended) builds.<br />
<br />
==== Prerequisites ====<br />
In addition with general [[#Prerequisites_2 | Prerequisites]], you'll need the OneAPI ISPC compiler.<br />
<br />
==== Conan cache interaction ====<br />
<br />
The build relies on the local Conan cache, which will be modified by the process. You may want to make a copy beforehand.<br />
<br />
In some scenarios, you may also want to reset your Conan cache (warning: may remove files unrelated to LuxCoreDeps):<br />
<pre>conan remove -c "*" # Be careful: may remove packages unrelated to LuxCoreDeps!</pre><br />
<br />
==== Run ====<br />
<br />
To run a plain local build, run the following statements in a console, from the root of LuxCoreDeps repository:<br />
<br />
<syntaxhighlight lang="python" line><br />
export RUNNER_OS=<os><br />
export RUNNER_ARCH=<arch><br />
<br />
export LUXDEPS_VERSION=test<br />
export GCC_VERSION=14 # Note: even for gcc > 14<br />
export WORKSPACE=.<br />
export CXX_VERSION=20<br />
export CMAKE_POLICY_VERSION_MINIMUM=3.25<br />
export DEPS_BUILD_TYPE=Release # Or Debug/RelWithDebInfo/MinSizeRel, if needed<br />
export cache_dir<br />
<br />
./run_conan.sh<br />
</syntaxhighlight><br />
<br />
with <code>RUNNER_OS</code>, <code>RUNNER_ARCH</code> in:<br />
* <code>Linux</code> / <code>X64</code><br />
* <code>Windows</code> / <code>X64</code><br />
* <code>macOS</code> / <code>X64</code><br />
* <code>macOS</code> / <code>ARM64</code><br />
reflecting your build platform.<br />
<br />
No detection is made (compiler, OS, arch...) . You'll have to do it on your own and set environment variables accordingly.<br />
<br />
==== Cleaning ====<br />
<br />
Conan will produce a bunch of scripts in the root of LuxCoreDeps repo. You can clean them with the following:<br />
<pre> ./utils/clean-conan-files.sh </pre><br />
<br />
=== Local Continuous Integration ===<br />
<br />
Run <code>act</code> on workflows located in <code>.github/workflows</code> folder, for instance <code>.github/workflows/build.yml</code> workflow.</br><br />
<br />
For more convenience, a wrapper script is also provided in <code>LuxCoreDeps</code> repository (Linux only, at the moment): <pre>./utils/local-CI-build.sh</pre><br />
<br />
=== Server Continuous Integration ===<br />
<br />
This process relies on the following Github workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/checker.yml <code>LuxCore Dependency Checker</code>].<br />
</br>Important points:<br />
* Your changes must have been committed and pushed to repository before.<br />
* The Checker workflow is actually also triggered on push event, so you may not have to run it by yourself<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
== Build LuxCore, Samples & Python Wheels ==<br />
<br />
=== Local Plain Build ===<br />
<br />
==== Prerequisites ====<br />
<br />
First, we will assume you have correctly completed the [[#Prerequisites_2 | Prerequisites]]. <br />
<br />
Second, we will also assume you've already git-cloned LuxCore on your local machine, opened a terminal, changed directory to LuxCore folder and git-checked out the branch that you want to build (+ for Windows: initialized build environment with <code>vcvarsall.bat</code>)<br />
<br />
==== Basic build ====<br />
<br />
Our build system internally relies on <code>cmake</code> but, for more convenience, everything has been wrapped into <code>make</code>-like statements.<br />
<br />
So, to build LuxCore, one just have to enter the following magic words:<br />
<pre><br />
make deps<br />
make<br />
</pre><br />
<br />
This should retrieve and install LuxCore dependencies, configure the project and run the build. That's all!<br />
<br />
<br />
For subsequent builds, if no modification have been made to dependencies, you'll just have to re-enter: <pre>make</pre><br />
<br />
==== Specific targets ====<br />
<br />
If you want to target a specific component, you can replace the above plain <code>make</code> by one of the following verbs:<br />
<pre>make luxcore</pre><br />
<pre>make pyluxcore</pre><br />
<pre>make luxcoreui</pre><br />
<pre>make luxcoreconsole</pre><br />
<br />
<br />
Starting from version 2.11, this method can build a "test wheel". This is a simplified wheel, only for current platform and current Python version, for testing purpose. The test wheel is particularly useful for developing/debugging LuxCore/BlendLuxCore integration.<br />
The verb is:<br />
<pre>make wheel-test</pre><br />
<br />
<br />
You can also build Doxygen documentation with the following statement:<br />
<pre>make doc</pre><br />
<br />
==== Build type ====<br />
<br />
By default, this method builds a release version, striped from all symbols. If you want to build a debug version, enter the following before any <code>make ...</code> command:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug</pre> <br />
<br />
==== Local dependency set ====<br />
<br />
It is possible to use a local dependency set, rather than relying on automatic downloading. It is especially useful for developing/debugging of LuxCoreDeps/LuxCore integration. In this case, one can replace the <code>make deps</code> statement by the following one:<br />
<br />
<pre><br />
python -m build-system.luxmake.deps --local <path/to/local/deps> --release <release><br />
</pre><br />
<br />
Nota: <code><release></code> is the release tag used by your local dependency set. If you build this set locally, it should likely be <code>test</code>.<br />
<br />
==== Cleaning ====<br />
<br />
You can remove build outputs with one of the following statement:<br />
<pre>make clean</pre><br />
or<br />
<pre>make clear</pre><br />
The former will remove build files, however preserving dependencies. <br />
The latter will remove everything and will require to reinstall dependencies (<code>make deps</code>).<br />
<br />
=== Local Continuous Integration ===<br />
<br />
This method is complementary to Local plain build, with the following additional capabilities:<br />
* test the LuxCore build in an environment close to the release environment (manylinux container, for instance)<br />
* can build wheels<br />
* debug any changes made to the build workflow<br />
<br />
It consists in running Github workflows locally, via <code>act</code>. Github workflows are located in <code>.github/workflows</code> folder.<br />
<br />
<code>act</code> invokation can be made on command line but, for convenience, a wrapper script is provided (for Linux): <pre>./build-helpers/debug/debug_wheels.sh</pre><br />
<br />
<i>Caveat: this build can produce wheels, but only for the host platform (no cross-compiling).</i><br />
<br />
=== Server Continuous Integration ===<br />
<br />
The process is nearly the same as publisher build, but the release steps are skipped. For that purpose, another Github workflow has to be executed: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-builder.yml <code>LuxCore Python Wheels Builder</code>].<br />
<br />
Please note that your changes must have been committed to repository before running the workflow.<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
= Publisher Workflows =<br />
<br />
== Prerequisites ==<br />
<br />
For these workflows, a Github account is required, with extended rights on the source repositories.<br />
<br />
== General Workflow ==<br />
<br />
The general workflow for publishing is in 3 parts:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
flowchart TD;<br />
subgraph Build["<center><b>BUILD & RELEASE DRAFT </br>(Run Releaser workflow)</b></center>"]<br />
padBuild(" "):::INVISIBLE<br />
repo("Go to <code>[Source repository]</code> on Github and open <code>Actions menu</code>")<br />
select("Select <code>[Releaser workflow]</code>")<br />
runwf(Click on <code>Run workflow</code> button, in the upper-right corner)<br />
branch(Select <code>Branch</code> in drop-down menu)<br />
options(Set workflow options)<br />
validate(Click <code>Run workflow</code>)<br />
wait(Wait for build to complete)<br />
end<br />
<br />
subgraph Release["<center><b>MAKE FINAL RELEASE</br>(Switch release to final status)</b></center>"]<br />
padRelease(" "):::INVISIBLE<br />
release("Open <code>[Release folder]</code>,</br> find the newly-built release (in Draft mode) </br> and edit it")<br />
complete(Add relevant information: change log, comments on version etc.)<br />
dedraft(Unset <code>Draft</code> checkbox)<br />
update(Click <code>Publish release</code>/<code>Update release</code> to finalize)<br />
end<br />
<br />
subgraph Deploy["<center><b>PUBLISH</br>(Run Publisher workflow)</b></center>"]<br />
padDeploy(" ")<br />
repoDeploy("Go to <code>[Source repository]</code> on Github and open <code>[Actions menu]</code>")<br />
selectDeploy("Select <code>[Publisher workflow]</code>")<br />
runwfDeploy("Click on <code>Run workflow</code> drop-down button, in the upper-right corner")<br />
choiceDeploy("Select <code>Branch</code>, set the <code>Tag to publish</code> and uncheck <code>Publish on Pypi Test</code> if needed")<br />
validateDeploy("Click on <code>Run workflow</code> button")<br />
waitDeploy("Wait for deployment to complete")<br />
end<br />
<br />
padBuild---repo<br />
repo-->select<br />
select-->runwf<br />
runwf-->branch<br />
branch-->options<br />
options-->validate<br />
validate-->wait:::WAIT<br />
linkStyle 0 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padRelease---release<br />
release-->complete<br />
complete-->dedraft<br />
dedraft-->update<br />
linkStyle 7 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padDeploy:::INVISIBLE---repoDeploy<br />
repoDeploy-->selectDeploy<br />
selectDeploy-->runwfDeploy<br />
runwfDeploy-->choiceDeploy<br />
choiceDeploy-->validateDeploy<br />
validateDeploy-->waitDeploy:::WAIT<br />
linkStyle 11 stroke:#fff,color:blue,stroke-width:0px;<br />
<br />
<br />
Build-- <i>if success</i> -->Release<br />
Release-- <i>if success & if needed</i> -->Deploy<br />
<br />
classDef WAIT fill:#ddd;<br />
classDef DEPS fill:#e4d8ff,stroke:#9488af;<br />
classDef INVISIBLE fill:#ffffffff,stroke:#ffffffff,stroke-width:0px,font-color:#ffffffff;<br />
classDef OPTIONAL stroke-dasharray: 5 5;<br />
<br />
class Deploy OPTIONAL;<br />
<br />
%% Note: padXXX is a poor hack to create a top-margin in subgraph...<br />
}}<br />
<br />
A few comments:<br />
* <code>[bracketed tokens]</code> refer to data specific to each component, which will be detailed below.<br />
* Publish part is optional, it will depends on the target<br />
* ''Caveat: if you provide an already-existing release version number during the process, the workflow will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.''<br />
<br />
== Per-target details ==<br />
<br />
=== External Dependencies ===<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreRender/LuxCoreDeps</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/release.yml <code>LuxCore Dependency Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCoreDeps/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
As a byproduct, External Dependencies are not intended to be deployed, so no Publisher workflow is provided.<br />
<br />
=== Python Wheels ===<br />
<br />
<br />
<br />
As far as wheels are concerned, in addition to building them, it is also necessary to upload them to [https://pypi.org/ PyPi] ("publish" them), so that they are available for [https://pypi.org/project/pip pip] installation.<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-releaser.yml <code>LuxCore Wheels Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-publisher.yml <code>LuxCore Wheels Publisher</code>]<br />
<br />
''Prerequisite: you must have released a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.''<br />
<br />
=== Samples ===<br />
<br />
As we plan to replace Samples by equivalent Python tools and thus deprecate them, the workflow has been limited to the Release part (no publish).<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/sample-releaser.yml <code>LuxCore Samples Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
=== BlendLuxCore ===<br />
<br />
<i>TODO</i><br />
<br />
= Version Management =<br />
<br />
== Semantic Versioning ==<br />
<br />
Starting for LuxCore version 2.10.0, we require that LuxCoreRender applies [https://semver.org/ Semantic Versioning]. Please strictly enforce this rule when incrementing version numbers.<br />
<br />
Remark: component versions does not have to be synced. For instance, in strict application of the standard, the newly created LuxCoreDeps will start at 1.0.0, while at the same time LuxCore is already at 2.10.0<br />
<br />
== Dependency Version pointer ==<br />
<br />
To make LuxCore know which version of dependencies it must be built against, we use a pointer.<br />
<br />
This pointer is stored in the file <code>build-helpers/build-settings.json</code>, under the path <code>Dependencies/release</code>.<br />
<br />
Make sure you keep it up-to-date when you upgrade LuxCore components.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender&diff=2681Building LuxCoreRender2026-04-24T04:16:04Z<p>Howetuft: /* Run */</p>
<hr />
<div>This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.<br />
<br />
LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all [[Building_LuxCoreRender_(legacy)|previous documents]] related to the compilation of older versions (<=2.9).<br />
<br />
<br />
<b>TL;DR</b> If you are just interested in a quick, local (but platform limited) compilation of LuxCore C++ samples or Python wheels, you may want to jump directly to [[#Build LuxCore, Samples & Python Wheels | Build LuxCore, Samples & Python Wheels]].</br><br />
<br />
<br />
<br />
= Audience =<br />
<br />
This document is intended for:<br />
* LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;<br />
* Developers wishing to contribute to the project;<br />
* External package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;<br />
<br />
This document assumes that the reader is skilled in the following areas:<br />
* C/C++ compilation<br />
* [https://cmake.org/ cmake]<br />
* [https://git-scm.com/ git]<br />
* [https://docs.github.com/en/actions/writing-workflows Github Workflows]<br />
* [https://packaging.python.org/en/latest/ Python Packaging], including [https://realpython.com/python-wheels/ Python Wheels format]<br />
<br />
Familiarity with [https://conan.io/ Conan] dependency manager may also help.<br />
<br />
</br><br />
This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries on the official [https://luxcorerender.org/download/ Download] page.<br />
<br />
= Build Targets =<br />
<br />
== Synoptic ==<br />
LuxCoreRender contains several build targets, below represented with dependency links:<br />
<br />
{{#mermaid:<br />
%%{<br />
init: {<br />
"theme": "forest",<br />
"logLevel": "info",<br />
"flowchart": {"curve": "basis"}<br />
}<br />
}%%<br />
<br />
flowchart LR;<br />
<br />
<br />
classDef TYPE font-weight:bold,font-size:1.1rem;<br />
classDef TARGET font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCOREDEPS fill:#ffe8ff,stroke:#9488af,font-weight:bold,font-size:1.1rem;<br />
classDef TARGETDEPS fill:#e4d8ff,stroke:#9488af,font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCORE fill:#bbceff,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETLUXCORE fill:#7799ee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef SAMPLES fill:#ffffdd,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETSAMPLES fill:#eeeecc,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef NEUTRAL fill:#fafafa,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETNEUTRAL fill:#eeeeee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef EXTDEP fill:#00000000,stroke:#00000000;<br />
<br />
<br />
subgraph Dependencies[External Dependencies]<br />
deps(LuxCore Dependencies)<br />
end<br />
<br />
class Dependencies LUXCOREDEPS;<br />
class deps TARGETDEPS;<br />
<br />
<br />
subgraph LuxCore<br />
lux(luxcore.so/.dll)<br />
luxa(luxcore.a)<br />
end<br />
class LuxCore LUXCORE;<br />
class lux TARGETLUXCORE;<br />
class luxa TARGETLUXCORE;<br />
<br />
subgraph Python_Wheels[Python Wheels]<br />
pylux(pyluxcore.so/.dll)<br />
wheels(LuxCore Python Wheels)<br />
end<br />
class Python_Wheels TYPE;<br />
class pylux TARGET;<br />
class wheels TARGET;<br />
<br />
subgraph Samples<br />
luxcoreui(luxcoreui)<br />
luxcoreconsole(luxcoreconsole)<br />
end<br />
class Samples SAMPLES;<br />
class luxcoreui TARGETSAMPLES;<br />
class luxcoreconsole TARGETSAMPLES;<br />
<br />
<br />
subgraph PyLuxCoreTools<br />
pyluxcon(pyluxcoreconsole)<br />
pyluxothers(...)<br />
end<br />
class PyLuxCoreTools NEUTRAL;<br />
class pyluxcon TARGETNEUTRAL;<br />
class pyluxothers TARGETNEUTRAL;<br />
<br />
subgraph Plugins[Python Plugins]<br />
blc(BlendLuxCore)<br />
otherplugins(...)<br />
end<br />
class blc TARGETNEUTRAL;<br />
class otherplugins TARGETNEUTRAL;<br />
<br />
class Plugins NEUTRAL;<br />
<br />
%% Warning: order matters<br />
deps-->lux<br />
deps-->luxa<br />
deps-->luxcoreui<br />
deps-->luxcoreconsole<br />
<br />
luxa--->pylux<br />
lux-->luxcoreui<br />
lux-->luxcoreconsole<br />
deps-->pylux<br />
<br />
<br />
<br />
pylux-->wheels<br />
wheels-. runtime .->blc<br />
wheels-. runtime .->otherplugins<br />
<br />
wheels-. runtime .->pyluxcon<br />
wheels-. runtime .->pyluxothers<br />
<br />
Python:::EXTDEP-->pylux<br />
<br />
<br />
%% Mermaid version: 8.14.0<br />
%% https://github.com/mermaid-js/mermaid/blob/8.14.0/src/defaultConfig.js<br />
<br />
<br />
<br />
}}<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! Target !! Source Repository !! Content<br />
|-<br />
| <b>External Dependencies</b>|| [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreDeps</code>] || A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to [https://github.com/LuxCoreRender/LuxCoreDeps/blob/main/README.md LuxCoreDeps README] for more information.<br />
|-<br />
| <b>LuxCore</b> || [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.<br />
|-<br />
| <b>Samples</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Sample C++ programs, illustrating luxcore use, namely <code>luxcoreconsole</code> and <code>luxcoreui</code><br />
|-<br />
| <b>Python Wheels</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version).</br> As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).<br />
|-<br />
| <b>Python Plugins</b>|| [https://github.com/LuxCoreRender/BlendLuxCore <code>BlendLuxCore</code>] etc. || Plugins to expose LuxCore in various external applications, notably Blender. </br> Written in Python and relying on Python Wheels as runtime dependency.<br />
|-<br />
| <b>PyLuxCoreTools</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python LuxCore Tools: set of command line tools based on pyluxcore, written in Python.<br />
|}<br />
<br />
== Targeted platforms ==<br />
<br />
LuxCoreRender aims at being available on the following 4 platforms:<br />
* Linux (glibc 2.28+)<br />
* Windows<br />
* MacOS Intel (>=10.15)<br />
* MacOS Arm (>=12.0)<br />
<br />
For Python-related targets, LuxCoreRender aims at being declined for [https://devguide.python.org/versions all Python versions supported at a given time].<br />
<br />
= Workflow Types =<br />
<br />
We distinguish between two types of build workflows:<br />
* Developer workflows<br />
* Publisher workflows<br />
<br />
<br />
''[[#Developer Workflows | Developer workflows]]'' are designed for development, debugging and test steps.<br />
<br />
Their purpose is to allow development and verify the code is ready for publication.<br />
<br />
<br />
''[[#Publisher Workflows | Publisher workflows]]'' are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.<br />
<br />
They exclusively take place in a CI/CD Github pipeline.<br />
<br />
These workflows are not designed for debugging or testing the underlying code. Execution of these workflows assumes that the development phase has been correctly completed and the underlying code is ready for final build and release. See [[#Developer Workflows | Developer Workflows]] to learn how to get code ready for final build.<br />
<br />
Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.<br />
<br />
= Developer Workflows =<br />
<br />
<br />
== Prerequisites ==<br />
<br />
<u>Tools</u><br />
<br />
You will need several build tools installed and referenced in the PATH.<br />
<br />
First, ensure you have a suitable toolchain:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! OS !! Compiler !! Minimal version<br />
|-<br />
| Windows || MSVC || 194x latest version<br />
|-<br />
| Linux|| gcc || 14<br />
|-<br />
| MacOS Intel|| XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|-<br />
| MacOS Arm || XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|}<br />
<br />
''Toolchain compliance is a very sensitive condition for a successful build. Before filing any claim, please check that your toolchain complies with the above requirements.''<br />
<br />
<br />
<br />
Then ensure the following software is also installed and available in your PATH:<br />
<br />
* [https://git-scm.com/ Git]<br />
* [https://cli.github.com/ Github CLI] (optional but recommended - for dependency signature checking)<br />
* [https://www.python.org/ Python 3] - any [https://devguide.python.org/versions/ currently supported version]<br />
* [https://conan.io Conan] latest version (pip install conan)<br />
* [https://github.com/pypa/wheel/tree/main Wheel] latest version (pip install wheel)<br />
* [https://cmake.org/ CMake] >= 3.29<br />
* [https://github.com/nektos/act nektos/act] (optional but recommended - for local build based on Github workflows)<br />
* [https://pypi.org/project/repairwheel repairwheel] (optional but recommended - for local build of test wheels)<br />
<br />
<br />
Platform specifics:<br />
* For Windows, ensure the command line is configured for building (<code>vcvarsall.bat</code>).<br />
* For Linux, you'll need <code>pkgconfig</code> in addition.<br />
* For MacOS, you'll need to ensure CC and CXX point to LLVM clang/clang++<br />
<br />
<u>Accounts</u><br />
<br />
A ''Github account'' is mandatory for LuxCore development.<br />
<br />
Following accounts are also recommended, in order to get in touch with LuxCore community:<br />
* [https://forums.luxcorerender.org/ LuxCoreRender Forums]<br />
* [https://discord.gg/chPGsKV LuxCoreRender Discord channel]<br />
<br />
== General Developer Workflow ==<br />
<br />
To compile and verify LuxCore component modifications in development process, there are 3 stages:<br />
* Local plain build: only run build system (cmake) on developer computer<br />
* Local Continuous Integration build: run full Continuous Integration workflow on developer computer<br />
* Server Continuous Integration build: run full Continuous Integration workflow on server<br />
<br />
<i>Local plain build</i> is generally faster than other builds and does not require to commit changes beforehand. Plain build installs a minimal build configuration (dependencies), but heavily relies on computer build environment for the rest (build tools, system libraries etc.). As a counterpart, it builds only for the platform where it is executed and can be significantly altered by local conditions (build tools local versions, dependency local versions etc.), thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<i>LocalCI </i> is generally faster than Server build, but slower than local plain build. CI workflow installs a complete build environment (compilers, sdk, build tools, containers, dependencies etc.) before running build system. It does not require to commit changes beforehand. However, it builds only for the platform where it is executed, thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<I>Server CI</i>, if successful, should guarantee success when publishing, as it occurs in conditions similar to release workflow (all platforms, complete build environment). As a counterpart, it is generally significantly slower than local builds and also implies to commit and push changes beforehand, even if the code is in unstable state.<br />
<br />
The recommended workflow thus strives to make the most of all stages:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
<br />
flowchart TD;<br />
<br />
fork(Fork Source repository in your own Github space)<br />
clone("Clone your fork locally</br><code>git clone...</code>")<br />
devel(Make modifications in your local fork)<br />
localBuild("<b>Run local plain build</b></br><code>cmake</code>, <code>make</code>...")<br />
localCI("<b>Run local CI</b></br><code>act</code>")<br />
git("Commit, Rebase & Push</br><code>git ...</code>")<br />
serverCI(<b>Run server CI</b></br><code>Github workflow</code>)<br />
PR(PR your changes to Source repository)<br />
<br />
fork-->clone<br />
clone-->devel<br />
devel-->localBuild<br />
localBuild-->localCI<br />
localCI-- "<i>Success</br>(including debug & tests)</i>" -->git<br />
git-->serverCI<br />
serverCI-- <i>Success</i> -->PR<br />
<br />
localBuild & localCI & serverCI ----> |<i>Failure</i>| devel<br />
<br />
classDef BUILD fill:#acc,stroke-width:4px;<br />
class localBuild BUILD;<br />
class localCI BUILD;<br />
class serverCI BUILD;<br />
<br />
}}<br />
<br />
This is the common process between all components. Each step will then be adapted to each component, as explained below.<br />
<br />
Comments:<br />
* Running local CI relies on [https://github.com/nektos/act <code>nektos/act</code>]<br />
* Rebase must be made against upstream directory (<code>git pull --rebase upstream <branch></code>)before pushing<br />
* Push must be made towards developer own fork. Caveat: do not try to push directly to upstream<br />
<br />
<br />
== Build External Dependencies ==<br />
<br />
=== Local Plain Build ===<br />
==== Caveats ====<br />
Dependency local plain build is possible but:<br />
* Local plain build IS NOT THE RECOMMENDED BUILD for final deps. This build is solely intended for intermediary development and debugging. No support will be provided when used out-of-scope.<br />
* Local plain build has only be tested on Linux, with gcc >=14. For other platforms, adaptations should be necessary (contributions welcome). <br />
* Local plain build is much impacted by local particulars (local compiler version, dependencies already in cache or in system dirs etc.) and therefore does not guarantee further success for other (recommended) builds.<br />
<br />
==== Prerequisites ====<br />
In addition with general [[#Prerequisites_2 | Prerequisites]], you'll need the OneAPI ISPC compiler.<br />
<br />
==== Conan cache interaction ====<br />
<br />
The build relies on the local Conan cache, which will be modified by the process. You may want to make a copy beforehand.<br />
<br />
In some scenarios, you may also want to reset your Conan cache (warning: may remove files unrelated to LuxCoreDeps):<br />
<pre>conan remove -c "*" # Be careful: may remove packages unrelated to LuxCoreDeps!</pre><br />
<br />
==== Run ====<br />
<br />
To run a plain local build, run the following statements in a console, from the root of LuxCoreDeps repository:<br />
<br />
<pre><br />
export RUNNER_OS=<os><br />
export RUNNER_ARCH=<arch><br />
<br />
export LUXDEPS_VERSION=test<br />
export GCC_VERSION=14 # Note: even for gcc > 14<br />
export WORKSPACE=.<br />
export CXX_VERSION=20<br />
export CMAKE_POLICY_VERSION_MINIMUM=3.25<br />
export DEPS_BUILD_TYPE=Release # Or Debug/RelWithDebInfo/MinSizeRel, if needed<br />
export cache_dir<br />
<br />
./run_conan.sh<br />
</pre><br />
<br />
with <code>RUNNER_OS</code>, <code>RUNNER_ARCH</code> in:<br />
* <code>Linux</code> / <code>X64</code><br />
* <code>Windows</code> / <code>X64</code><br />
* <code>macOS</code> / <code>X64</code><br />
* <code>macOS</code> / <code>ARM64</code><br />
reflecting your build platform.<br />
<br />
No detection is made (compiler, OS, arch...) . You'll have to do it on your own and set environment variables accordingly.<br />
<br />
==== Cleaning ====<br />
<br />
Conan will produce a bunch of scripts in the root of LuxCoreDeps repo. You can clean them with the following:<br />
<pre> ./utils/clean-conan-files.sh </pre><br />
<br />
=== Local Continuous Integration ===<br />
<br />
Run <code>act</code> on workflows located in <code>.github/workflows</code> folder, for instance <code>.github/workflows/build.yml</code> workflow.</br><br />
<br />
For more convenience, a wrapper script is also provided in <code>LuxCoreDeps</code> repository (Linux only, at the moment): <pre>./utils/local-CI-build.sh</pre><br />
<br />
=== Server Continuous Integration ===<br />
<br />
This process relies on the following Github workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/checker.yml <code>LuxCore Dependency Checker</code>].<br />
</br>Important points:<br />
* Your changes must have been committed and pushed to repository before.<br />
* The Checker workflow is actually also triggered on push event, so you may not have to run it by yourself<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
== Build LuxCore, Samples & Python Wheels ==<br />
<br />
=== Local Plain Build ===<br />
<br />
==== Prerequisites ====<br />
<br />
First, we will assume you have correctly completed the [[#Prerequisites_2 | Prerequisites]]. <br />
<br />
Second, we will also assume you've already git-cloned LuxCore on your local machine, opened a terminal, changed directory to LuxCore folder and git-checked out the branch that you want to build (+ for Windows: initialized build environment with <code>vcvarsall.bat</code>)<br />
<br />
==== Basic build ====<br />
<br />
Our build system internally relies on <code>cmake</code> but, for more convenience, everything has been wrapped into <code>make</code>-like statements.<br />
<br />
So, to build LuxCore, one just have to enter the following magic words:<br />
<pre><br />
make deps<br />
make<br />
</pre><br />
<br />
This should retrieve and install LuxCore dependencies, configure the project and run the build. That's all!<br />
<br />
<br />
For subsequent builds, if no modification have been made to dependencies, you'll just have to re-enter: <pre>make</pre><br />
<br />
==== Specific targets ====<br />
<br />
If you want to target a specific component, you can replace the above plain <code>make</code> by one of the following verbs:<br />
<pre>make luxcore</pre><br />
<pre>make pyluxcore</pre><br />
<pre>make luxcoreui</pre><br />
<pre>make luxcoreconsole</pre><br />
<br />
<br />
Starting from version 2.11, this method can build a "test wheel". This is a simplified wheel, only for current platform and current Python version, for testing purpose. The test wheel is particularly useful for developing/debugging LuxCore/BlendLuxCore integration.<br />
The verb is:<br />
<pre>make wheel-test</pre><br />
<br />
<br />
You can also build Doxygen documentation with the following statement:<br />
<pre>make doc</pre><br />
<br />
==== Build type ====<br />
<br />
By default, this method builds a release version, striped from all symbols. If you want to build a debug version, enter the following before any <code>make ...</code> command:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug</pre> <br />
<br />
==== Local dependency set ====<br />
<br />
It is possible to use a local dependency set, rather than relying on automatic downloading. It is especially useful for developing/debugging of LuxCoreDeps/LuxCore integration. In this case, one can replace the <code>make deps</code> statement by the following one:<br />
<br />
<pre><br />
python -m build-system.luxmake.deps --local <path/to/local/deps> --release <release><br />
</pre><br />
<br />
Nota: <code><release></code> is the release tag used by your local dependency set. If you build this set locally, it should likely be <code>test</code>.<br />
<br />
==== Cleaning ====<br />
<br />
You can remove build outputs with one of the following statement:<br />
<pre>make clean</pre><br />
or<br />
<pre>make clear</pre><br />
The former will remove build files, however preserving dependencies. <br />
The latter will remove everything and will require to reinstall dependencies (<code>make deps</code>).<br />
<br />
=== Local Continuous Integration ===<br />
<br />
This method is complementary to Local plain build, with the following additional capabilities:<br />
* test the LuxCore build in an environment close to the release environment (manylinux container, for instance)<br />
* can build wheels<br />
* debug any changes made to the build workflow<br />
<br />
It consists in running Github workflows locally, via <code>act</code>. Github workflows are located in <code>.github/workflows</code> folder.<br />
<br />
<code>act</code> invokation can be made on command line but, for convenience, a wrapper script is provided (for Linux): <pre>./build-helpers/debug/debug_wheels.sh</pre><br />
<br />
<i>Caveat: this build can produce wheels, but only for the host platform (no cross-compiling).</i><br />
<br />
=== Server Continuous Integration ===<br />
<br />
The process is nearly the same as publisher build, but the release steps are skipped. For that purpose, another Github workflow has to be executed: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-builder.yml <code>LuxCore Python Wheels Builder</code>].<br />
<br />
Please note that your changes must have been committed to repository before running the workflow.<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
= Publisher Workflows =<br />
<br />
== Prerequisites ==<br />
<br />
For these workflows, a Github account is required, with extended rights on the source repositories.<br />
<br />
== General Workflow ==<br />
<br />
The general workflow for publishing is in 3 parts:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
flowchart TD;<br />
subgraph Build["<center><b>BUILD & RELEASE DRAFT </br>(Run Releaser workflow)</b></center>"]<br />
padBuild(" "):::INVISIBLE<br />
repo("Go to <code>[Source repository]</code> on Github and open <code>Actions menu</code>")<br />
select("Select <code>[Releaser workflow]</code>")<br />
runwf(Click on <code>Run workflow</code> button, in the upper-right corner)<br />
branch(Select <code>Branch</code> in drop-down menu)<br />
options(Set workflow options)<br />
validate(Click <code>Run workflow</code>)<br />
wait(Wait for build to complete)<br />
end<br />
<br />
subgraph Release["<center><b>MAKE FINAL RELEASE</br>(Switch release to final status)</b></center>"]<br />
padRelease(" "):::INVISIBLE<br />
release("Open <code>[Release folder]</code>,</br> find the newly-built release (in Draft mode) </br> and edit it")<br />
complete(Add relevant information: change log, comments on version etc.)<br />
dedraft(Unset <code>Draft</code> checkbox)<br />
update(Click <code>Publish release</code>/<code>Update release</code> to finalize)<br />
end<br />
<br />
subgraph Deploy["<center><b>PUBLISH</br>(Run Publisher workflow)</b></center>"]<br />
padDeploy(" ")<br />
repoDeploy("Go to <code>[Source repository]</code> on Github and open <code>[Actions menu]</code>")<br />
selectDeploy("Select <code>[Publisher workflow]</code>")<br />
runwfDeploy("Click on <code>Run workflow</code> drop-down button, in the upper-right corner")<br />
choiceDeploy("Select <code>Branch</code>, set the <code>Tag to publish</code> and uncheck <code>Publish on Pypi Test</code> if needed")<br />
validateDeploy("Click on <code>Run workflow</code> button")<br />
waitDeploy("Wait for deployment to complete")<br />
end<br />
<br />
padBuild---repo<br />
repo-->select<br />
select-->runwf<br />
runwf-->branch<br />
branch-->options<br />
options-->validate<br />
validate-->wait:::WAIT<br />
linkStyle 0 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padRelease---release<br />
release-->complete<br />
complete-->dedraft<br />
dedraft-->update<br />
linkStyle 7 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padDeploy:::INVISIBLE---repoDeploy<br />
repoDeploy-->selectDeploy<br />
selectDeploy-->runwfDeploy<br />
runwfDeploy-->choiceDeploy<br />
choiceDeploy-->validateDeploy<br />
validateDeploy-->waitDeploy:::WAIT<br />
linkStyle 11 stroke:#fff,color:blue,stroke-width:0px;<br />
<br />
<br />
Build-- <i>if success</i> -->Release<br />
Release-- <i>if success & if needed</i> -->Deploy<br />
<br />
classDef WAIT fill:#ddd;<br />
classDef DEPS fill:#e4d8ff,stroke:#9488af;<br />
classDef INVISIBLE fill:#ffffffff,stroke:#ffffffff,stroke-width:0px,font-color:#ffffffff;<br />
classDef OPTIONAL stroke-dasharray: 5 5;<br />
<br />
class Deploy OPTIONAL;<br />
<br />
%% Note: padXXX is a poor hack to create a top-margin in subgraph...<br />
}}<br />
<br />
A few comments:<br />
* <code>[bracketed tokens]</code> refer to data specific to each component, which will be detailed below.<br />
* Publish part is optional, it will depends on the target<br />
* ''Caveat: if you provide an already-existing release version number during the process, the workflow will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.''<br />
<br />
== Per-target details ==<br />
<br />
=== External Dependencies ===<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreRender/LuxCoreDeps</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/release.yml <code>LuxCore Dependency Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCoreDeps/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
As a byproduct, External Dependencies are not intended to be deployed, so no Publisher workflow is provided.<br />
<br />
=== Python Wheels ===<br />
<br />
<br />
<br />
As far as wheels are concerned, in addition to building them, it is also necessary to upload them to [https://pypi.org/ PyPi] ("publish" them), so that they are available for [https://pypi.org/project/pip pip] installation.<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-releaser.yml <code>LuxCore Wheels Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-publisher.yml <code>LuxCore Wheels Publisher</code>]<br />
<br />
''Prerequisite: you must have released a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.''<br />
<br />
=== Samples ===<br />
<br />
As we plan to replace Samples by equivalent Python tools and thus deprecate them, the workflow has been limited to the Release part (no publish).<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/sample-releaser.yml <code>LuxCore Samples Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
=== BlendLuxCore ===<br />
<br />
<i>TODO</i><br />
<br />
= Version Management =<br />
<br />
== Semantic Versioning ==<br />
<br />
Starting for LuxCore version 2.10.0, we require that LuxCoreRender applies [https://semver.org/ Semantic Versioning]. Please strictly enforce this rule when incrementing version numbers.<br />
<br />
Remark: component versions does not have to be synced. For instance, in strict application of the standard, the newly created LuxCoreDeps will start at 1.0.0, while at the same time LuxCore is already at 2.10.0<br />
<br />
== Dependency Version pointer ==<br />
<br />
To make LuxCore know which version of dependencies it must be built against, we use a pointer.<br />
<br />
This pointer is stored in the file <code>build-helpers/build-settings.json</code>, under the path <code>Dependencies/release</code>.<br />
<br />
Make sure you keep it up-to-date when you upgrade LuxCore components.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender&diff=2680Building LuxCoreRender2026-04-24T04:13:07Z<p>Howetuft: /* Prerequisites */</p>
<hr />
<div>This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.<br />
<br />
LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all [[Building_LuxCoreRender_(legacy)|previous documents]] related to the compilation of older versions (<=2.9).<br />
<br />
<br />
<b>TL;DR</b> If you are just interested in a quick, local (but platform limited) compilation of LuxCore C++ samples or Python wheels, you may want to jump directly to [[#Build LuxCore, Samples & Python Wheels | Build LuxCore, Samples & Python Wheels]].</br><br />
<br />
<br />
<br />
= Audience =<br />
<br />
This document is intended for:<br />
* LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;<br />
* Developers wishing to contribute to the project;<br />
* External package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;<br />
<br />
This document assumes that the reader is skilled in the following areas:<br />
* C/C++ compilation<br />
* [https://cmake.org/ cmake]<br />
* [https://git-scm.com/ git]<br />
* [https://docs.github.com/en/actions/writing-workflows Github Workflows]<br />
* [https://packaging.python.org/en/latest/ Python Packaging], including [https://realpython.com/python-wheels/ Python Wheels format]<br />
<br />
Familiarity with [https://conan.io/ Conan] dependency manager may also help.<br />
<br />
</br><br />
This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries on the official [https://luxcorerender.org/download/ Download] page.<br />
<br />
= Build Targets =<br />
<br />
== Synoptic ==<br />
LuxCoreRender contains several build targets, below represented with dependency links:<br />
<br />
{{#mermaid:<br />
%%{<br />
init: {<br />
"theme": "forest",<br />
"logLevel": "info",<br />
"flowchart": {"curve": "basis"}<br />
}<br />
}%%<br />
<br />
flowchart LR;<br />
<br />
<br />
classDef TYPE font-weight:bold,font-size:1.1rem;<br />
classDef TARGET font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCOREDEPS fill:#ffe8ff,stroke:#9488af,font-weight:bold,font-size:1.1rem;<br />
classDef TARGETDEPS fill:#e4d8ff,stroke:#9488af,font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCORE fill:#bbceff,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETLUXCORE fill:#7799ee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef SAMPLES fill:#ffffdd,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETSAMPLES fill:#eeeecc,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef NEUTRAL fill:#fafafa,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETNEUTRAL fill:#eeeeee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef EXTDEP fill:#00000000,stroke:#00000000;<br />
<br />
<br />
subgraph Dependencies[External Dependencies]<br />
deps(LuxCore Dependencies)<br />
end<br />
<br />
class Dependencies LUXCOREDEPS;<br />
class deps TARGETDEPS;<br />
<br />
<br />
subgraph LuxCore<br />
lux(luxcore.so/.dll)<br />
luxa(luxcore.a)<br />
end<br />
class LuxCore LUXCORE;<br />
class lux TARGETLUXCORE;<br />
class luxa TARGETLUXCORE;<br />
<br />
subgraph Python_Wheels[Python Wheels]<br />
pylux(pyluxcore.so/.dll)<br />
wheels(LuxCore Python Wheels)<br />
end<br />
class Python_Wheels TYPE;<br />
class pylux TARGET;<br />
class wheels TARGET;<br />
<br />
subgraph Samples<br />
luxcoreui(luxcoreui)<br />
luxcoreconsole(luxcoreconsole)<br />
end<br />
class Samples SAMPLES;<br />
class luxcoreui TARGETSAMPLES;<br />
class luxcoreconsole TARGETSAMPLES;<br />
<br />
<br />
subgraph PyLuxCoreTools<br />
pyluxcon(pyluxcoreconsole)<br />
pyluxothers(...)<br />
end<br />
class PyLuxCoreTools NEUTRAL;<br />
class pyluxcon TARGETNEUTRAL;<br />
class pyluxothers TARGETNEUTRAL;<br />
<br />
subgraph Plugins[Python Plugins]<br />
blc(BlendLuxCore)<br />
otherplugins(...)<br />
end<br />
class blc TARGETNEUTRAL;<br />
class otherplugins TARGETNEUTRAL;<br />
<br />
class Plugins NEUTRAL;<br />
<br />
%% Warning: order matters<br />
deps-->lux<br />
deps-->luxa<br />
deps-->luxcoreui<br />
deps-->luxcoreconsole<br />
<br />
luxa--->pylux<br />
lux-->luxcoreui<br />
lux-->luxcoreconsole<br />
deps-->pylux<br />
<br />
<br />
<br />
pylux-->wheels<br />
wheels-. runtime .->blc<br />
wheels-. runtime .->otherplugins<br />
<br />
wheels-. runtime .->pyluxcon<br />
wheels-. runtime .->pyluxothers<br />
<br />
Python:::EXTDEP-->pylux<br />
<br />
<br />
%% Mermaid version: 8.14.0<br />
%% https://github.com/mermaid-js/mermaid/blob/8.14.0/src/defaultConfig.js<br />
<br />
<br />
<br />
}}<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! Target !! Source Repository !! Content<br />
|-<br />
| <b>External Dependencies</b>|| [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreDeps</code>] || A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to [https://github.com/LuxCoreRender/LuxCoreDeps/blob/main/README.md LuxCoreDeps README] for more information.<br />
|-<br />
| <b>LuxCore</b> || [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.<br />
|-<br />
| <b>Samples</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Sample C++ programs, illustrating luxcore use, namely <code>luxcoreconsole</code> and <code>luxcoreui</code><br />
|-<br />
| <b>Python Wheels</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version).</br> As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).<br />
|-<br />
| <b>Python Plugins</b>|| [https://github.com/LuxCoreRender/BlendLuxCore <code>BlendLuxCore</code>] etc. || Plugins to expose LuxCore in various external applications, notably Blender. </br> Written in Python and relying on Python Wheels as runtime dependency.<br />
|-<br />
| <b>PyLuxCoreTools</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python LuxCore Tools: set of command line tools based on pyluxcore, written in Python.<br />
|}<br />
<br />
== Targeted platforms ==<br />
<br />
LuxCoreRender aims at being available on the following 4 platforms:<br />
* Linux (glibc 2.28+)<br />
* Windows<br />
* MacOS Intel (>=10.15)<br />
* MacOS Arm (>=12.0)<br />
<br />
For Python-related targets, LuxCoreRender aims at being declined for [https://devguide.python.org/versions all Python versions supported at a given time].<br />
<br />
= Workflow Types =<br />
<br />
We distinguish between two types of build workflows:<br />
* Developer workflows<br />
* Publisher workflows<br />
<br />
<br />
''[[#Developer Workflows | Developer workflows]]'' are designed for development, debugging and test steps.<br />
<br />
Their purpose is to allow development and verify the code is ready for publication.<br />
<br />
<br />
''[[#Publisher Workflows | Publisher workflows]]'' are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.<br />
<br />
They exclusively take place in a CI/CD Github pipeline.<br />
<br />
These workflows are not designed for debugging or testing the underlying code. Execution of these workflows assumes that the development phase has been correctly completed and the underlying code is ready for final build and release. See [[#Developer Workflows | Developer Workflows]] to learn how to get code ready for final build.<br />
<br />
Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.<br />
<br />
= Developer Workflows =<br />
<br />
<br />
== Prerequisites ==<br />
<br />
<u>Tools</u><br />
<br />
You will need several build tools installed and referenced in the PATH.<br />
<br />
First, ensure you have a suitable toolchain:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! OS !! Compiler !! Minimal version<br />
|-<br />
| Windows || MSVC || 194x latest version<br />
|-<br />
| Linux|| gcc || 14<br />
|-<br />
| MacOS Intel|| XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|-<br />
| MacOS Arm || XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|}<br />
<br />
''Toolchain compliance is a very sensitive condition for a successful build. Before filing any claim, please check that your toolchain complies with the above requirements.''<br />
<br />
<br />
<br />
Then ensure the following software is also installed and available in your PATH:<br />
<br />
* [https://git-scm.com/ Git]<br />
* [https://cli.github.com/ Github CLI] (optional but recommended - for dependency signature checking)<br />
* [https://www.python.org/ Python 3] - any [https://devguide.python.org/versions/ currently supported version]<br />
* [https://conan.io Conan] latest version (pip install conan)<br />
* [https://github.com/pypa/wheel/tree/main Wheel] latest version (pip install wheel)<br />
* [https://cmake.org/ CMake] >= 3.29<br />
* [https://github.com/nektos/act nektos/act] (optional but recommended - for local build based on Github workflows)<br />
* [https://pypi.org/project/repairwheel repairwheel] (optional but recommended - for local build of test wheels)<br />
<br />
<br />
Platform specifics:<br />
* For Windows, ensure the command line is configured for building (<code>vcvarsall.bat</code>).<br />
* For Linux, you'll need <code>pkgconfig</code> in addition.<br />
* For MacOS, you'll need to ensure CC and CXX point to LLVM clang/clang++<br />
<br />
<u>Accounts</u><br />
<br />
A ''Github account'' is mandatory for LuxCore development.<br />
<br />
Following accounts are also recommended, in order to get in touch with LuxCore community:<br />
* [https://forums.luxcorerender.org/ LuxCoreRender Forums]<br />
* [https://discord.gg/chPGsKV LuxCoreRender Discord channel]<br />
<br />
== General Developer Workflow ==<br />
<br />
To compile and verify LuxCore component modifications in development process, there are 3 stages:<br />
* Local plain build: only run build system (cmake) on developer computer<br />
* Local Continuous Integration build: run full Continuous Integration workflow on developer computer<br />
* Server Continuous Integration build: run full Continuous Integration workflow on server<br />
<br />
<i>Local plain build</i> is generally faster than other builds and does not require to commit changes beforehand. Plain build installs a minimal build configuration (dependencies), but heavily relies on computer build environment for the rest (build tools, system libraries etc.). As a counterpart, it builds only for the platform where it is executed and can be significantly altered by local conditions (build tools local versions, dependency local versions etc.), thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<i>LocalCI </i> is generally faster than Server build, but slower than local plain build. CI workflow installs a complete build environment (compilers, sdk, build tools, containers, dependencies etc.) before running build system. It does not require to commit changes beforehand. However, it builds only for the platform where it is executed, thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<I>Server CI</i>, if successful, should guarantee success when publishing, as it occurs in conditions similar to release workflow (all platforms, complete build environment). As a counterpart, it is generally significantly slower than local builds and also implies to commit and push changes beforehand, even if the code is in unstable state.<br />
<br />
The recommended workflow thus strives to make the most of all stages:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
<br />
flowchart TD;<br />
<br />
fork(Fork Source repository in your own Github space)<br />
clone("Clone your fork locally</br><code>git clone...</code>")<br />
devel(Make modifications in your local fork)<br />
localBuild("<b>Run local plain build</b></br><code>cmake</code>, <code>make</code>...")<br />
localCI("<b>Run local CI</b></br><code>act</code>")<br />
git("Commit, Rebase & Push</br><code>git ...</code>")<br />
serverCI(<b>Run server CI</b></br><code>Github workflow</code>)<br />
PR(PR your changes to Source repository)<br />
<br />
fork-->clone<br />
clone-->devel<br />
devel-->localBuild<br />
localBuild-->localCI<br />
localCI-- "<i>Success</br>(including debug & tests)</i>" -->git<br />
git-->serverCI<br />
serverCI-- <i>Success</i> -->PR<br />
<br />
localBuild & localCI & serverCI ----> |<i>Failure</i>| devel<br />
<br />
classDef BUILD fill:#acc,stroke-width:4px;<br />
class localBuild BUILD;<br />
class localCI BUILD;<br />
class serverCI BUILD;<br />
<br />
}}<br />
<br />
This is the common process between all components. Each step will then be adapted to each component, as explained below.<br />
<br />
Comments:<br />
* Running local CI relies on [https://github.com/nektos/act <code>nektos/act</code>]<br />
* Rebase must be made against upstream directory (<code>git pull --rebase upstream <branch></code>)before pushing<br />
* Push must be made towards developer own fork. Caveat: do not try to push directly to upstream<br />
<br />
<br />
== Build External Dependencies ==<br />
<br />
=== Local Plain Build ===<br />
==== Caveats ====<br />
Dependency local plain build is possible but:<br />
* Local plain build IS NOT THE RECOMMENDED BUILD for final deps. This build is solely intended for intermediary development and debugging. No support will be provided when used out-of-scope.<br />
* Local plain build has only be tested on Linux, with gcc >=14. For other platforms, adaptations should be necessary (contributions welcome). <br />
* Local plain build is much impacted by local particulars (local compiler version, dependencies already in cache or in system dirs etc.) and therefore does not guarantee further success for other (recommended) builds.<br />
<br />
==== Prerequisites ====<br />
In addition with general [[#Prerequisites_2 | Prerequisites]], you'll need the OneAPI ISPC compiler.<br />
<br />
==== Conan cache interaction ====<br />
<br />
The build relies on the local Conan cache, which will be modified by the process. You may want to make a copy beforehand.<br />
<br />
In some scenarios, you may also want to reset your Conan cache (warning: may remove files unrelated to LuxCoreDeps):<br />
<pre>conan remove -c "*" # Be careful: may remove packages unrelated to LuxCoreDeps!</pre><br />
<br />
==== Run ====<br />
<br />
To run a plain local build, run the following statements in a console, from the root of LuxCoreDeps repository:<br />
<br />
<pre><br />
export RUNNER_OS=<os><br />
export RUNNER_ARCH=<arch><br />
<br />
export LUXDEPS_VERSION=test<br />
export GCC_VERSION=14 # Note: even for gcc > 14<br />
export WORKSPACE=.<br />
export CXX_VERSION=20<br />
export CMAKE_POLICY_VERSION_MINIMUM=3.25<br />
export cache_dir<br />
<br />
./run_conan.sh<br />
</pre><br />
<br />
with <code>RUNNER_OS</code>, <code>RUNNER_ARCH</code> in:<br />
* <code>Linux</code> / <code>X64</code><br />
* <code>Windows</code> / <code>X64</code><br />
* <code>macOS</code> / <code>X64</code><br />
* <code>macOS</code> / <code>ARM64</code><br />
reflecting your build platform.<br />
<br />
No detection is made (compiler, OS, arch...) . You'll have to do it on your own and set environment variables accordingly.<br />
<br />
==== Cleaning ====<br />
<br />
Conan will produce a bunch of scripts in the root of LuxCoreDeps repo. You can clean them with the following:<br />
<pre> ./utils/clean-conan-files.sh </pre><br />
<br />
=== Local Continuous Integration ===<br />
<br />
Run <code>act</code> on workflows located in <code>.github/workflows</code> folder, for instance <code>.github/workflows/build.yml</code> workflow.</br><br />
<br />
For more convenience, a wrapper script is also provided in <code>LuxCoreDeps</code> repository (Linux only, at the moment): <pre>./utils/local-CI-build.sh</pre><br />
<br />
=== Server Continuous Integration ===<br />
<br />
This process relies on the following Github workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/checker.yml <code>LuxCore Dependency Checker</code>].<br />
</br>Important points:<br />
* Your changes must have been committed and pushed to repository before.<br />
* The Checker workflow is actually also triggered on push event, so you may not have to run it by yourself<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
== Build LuxCore, Samples & Python Wheels ==<br />
<br />
=== Local Plain Build ===<br />
<br />
==== Prerequisites ====<br />
<br />
First, we will assume you have correctly completed the [[#Prerequisites_2 | Prerequisites]]. <br />
<br />
Second, we will also assume you've already git-cloned LuxCore on your local machine, opened a terminal, changed directory to LuxCore folder and git-checked out the branch that you want to build (+ for Windows: initialized build environment with <code>vcvarsall.bat</code>)<br />
<br />
==== Basic build ====<br />
<br />
Our build system internally relies on <code>cmake</code> but, for more convenience, everything has been wrapped into <code>make</code>-like statements.<br />
<br />
So, to build LuxCore, one just have to enter the following magic words:<br />
<pre><br />
make deps<br />
make<br />
</pre><br />
<br />
This should retrieve and install LuxCore dependencies, configure the project and run the build. That's all!<br />
<br />
<br />
For subsequent builds, if no modification have been made to dependencies, you'll just have to re-enter: <pre>make</pre><br />
<br />
==== Specific targets ====<br />
<br />
If you want to target a specific component, you can replace the above plain <code>make</code> by one of the following verbs:<br />
<pre>make luxcore</pre><br />
<pre>make pyluxcore</pre><br />
<pre>make luxcoreui</pre><br />
<pre>make luxcoreconsole</pre><br />
<br />
<br />
Starting from version 2.11, this method can build a "test wheel". This is a simplified wheel, only for current platform and current Python version, for testing purpose. The test wheel is particularly useful for developing/debugging LuxCore/BlendLuxCore integration.<br />
The verb is:<br />
<pre>make wheel-test</pre><br />
<br />
<br />
You can also build Doxygen documentation with the following statement:<br />
<pre>make doc</pre><br />
<br />
==== Build type ====<br />
<br />
By default, this method builds a release version, striped from all symbols. If you want to build a debug version, enter the following before any <code>make ...</code> command:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug</pre> <br />
<br />
==== Local dependency set ====<br />
<br />
It is possible to use a local dependency set, rather than relying on automatic downloading. It is especially useful for developing/debugging of LuxCoreDeps/LuxCore integration. In this case, one can replace the <code>make deps</code> statement by the following one:<br />
<br />
<pre><br />
python -m build-system.luxmake.deps --local <path/to/local/deps> --release <release><br />
</pre><br />
<br />
Nota: <code><release></code> is the release tag used by your local dependency set. If you build this set locally, it should likely be <code>test</code>.<br />
<br />
==== Cleaning ====<br />
<br />
You can remove build outputs with one of the following statement:<br />
<pre>make clean</pre><br />
or<br />
<pre>make clear</pre><br />
The former will remove build files, however preserving dependencies. <br />
The latter will remove everything and will require to reinstall dependencies (<code>make deps</code>).<br />
<br />
=== Local Continuous Integration ===<br />
<br />
This method is complementary to Local plain build, with the following additional capabilities:<br />
* test the LuxCore build in an environment close to the release environment (manylinux container, for instance)<br />
* can build wheels<br />
* debug any changes made to the build workflow<br />
<br />
It consists in running Github workflows locally, via <code>act</code>. Github workflows are located in <code>.github/workflows</code> folder.<br />
<br />
<code>act</code> invokation can be made on command line but, for convenience, a wrapper script is provided (for Linux): <pre>./build-helpers/debug/debug_wheels.sh</pre><br />
<br />
<i>Caveat: this build can produce wheels, but only for the host platform (no cross-compiling).</i><br />
<br />
=== Server Continuous Integration ===<br />
<br />
The process is nearly the same as publisher build, but the release steps are skipped. For that purpose, another Github workflow has to be executed: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-builder.yml <code>LuxCore Python Wheels Builder</code>].<br />
<br />
Please note that your changes must have been committed to repository before running the workflow.<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
= Publisher Workflows =<br />
<br />
== Prerequisites ==<br />
<br />
For these workflows, a Github account is required, with extended rights on the source repositories.<br />
<br />
== General Workflow ==<br />
<br />
The general workflow for publishing is in 3 parts:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
flowchart TD;<br />
subgraph Build["<center><b>BUILD & RELEASE DRAFT </br>(Run Releaser workflow)</b></center>"]<br />
padBuild(" "):::INVISIBLE<br />
repo("Go to <code>[Source repository]</code> on Github and open <code>Actions menu</code>")<br />
select("Select <code>[Releaser workflow]</code>")<br />
runwf(Click on <code>Run workflow</code> button, in the upper-right corner)<br />
branch(Select <code>Branch</code> in drop-down menu)<br />
options(Set workflow options)<br />
validate(Click <code>Run workflow</code>)<br />
wait(Wait for build to complete)<br />
end<br />
<br />
subgraph Release["<center><b>MAKE FINAL RELEASE</br>(Switch release to final status)</b></center>"]<br />
padRelease(" "):::INVISIBLE<br />
release("Open <code>[Release folder]</code>,</br> find the newly-built release (in Draft mode) </br> and edit it")<br />
complete(Add relevant information: change log, comments on version etc.)<br />
dedraft(Unset <code>Draft</code> checkbox)<br />
update(Click <code>Publish release</code>/<code>Update release</code> to finalize)<br />
end<br />
<br />
subgraph Deploy["<center><b>PUBLISH</br>(Run Publisher workflow)</b></center>"]<br />
padDeploy(" ")<br />
repoDeploy("Go to <code>[Source repository]</code> on Github and open <code>[Actions menu]</code>")<br />
selectDeploy("Select <code>[Publisher workflow]</code>")<br />
runwfDeploy("Click on <code>Run workflow</code> drop-down button, in the upper-right corner")<br />
choiceDeploy("Select <code>Branch</code>, set the <code>Tag to publish</code> and uncheck <code>Publish on Pypi Test</code> if needed")<br />
validateDeploy("Click on <code>Run workflow</code> button")<br />
waitDeploy("Wait for deployment to complete")<br />
end<br />
<br />
padBuild---repo<br />
repo-->select<br />
select-->runwf<br />
runwf-->branch<br />
branch-->options<br />
options-->validate<br />
validate-->wait:::WAIT<br />
linkStyle 0 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padRelease---release<br />
release-->complete<br />
complete-->dedraft<br />
dedraft-->update<br />
linkStyle 7 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padDeploy:::INVISIBLE---repoDeploy<br />
repoDeploy-->selectDeploy<br />
selectDeploy-->runwfDeploy<br />
runwfDeploy-->choiceDeploy<br />
choiceDeploy-->validateDeploy<br />
validateDeploy-->waitDeploy:::WAIT<br />
linkStyle 11 stroke:#fff,color:blue,stroke-width:0px;<br />
<br />
<br />
Build-- <i>if success</i> -->Release<br />
Release-- <i>if success & if needed</i> -->Deploy<br />
<br />
classDef WAIT fill:#ddd;<br />
classDef DEPS fill:#e4d8ff,stroke:#9488af;<br />
classDef INVISIBLE fill:#ffffffff,stroke:#ffffffff,stroke-width:0px,font-color:#ffffffff;<br />
classDef OPTIONAL stroke-dasharray: 5 5;<br />
<br />
class Deploy OPTIONAL;<br />
<br />
%% Note: padXXX is a poor hack to create a top-margin in subgraph...<br />
}}<br />
<br />
A few comments:<br />
* <code>[bracketed tokens]</code> refer to data specific to each component, which will be detailed below.<br />
* Publish part is optional, it will depends on the target<br />
* ''Caveat: if you provide an already-existing release version number during the process, the workflow will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.''<br />
<br />
== Per-target details ==<br />
<br />
=== External Dependencies ===<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreRender/LuxCoreDeps</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/release.yml <code>LuxCore Dependency Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCoreDeps/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
As a byproduct, External Dependencies are not intended to be deployed, so no Publisher workflow is provided.<br />
<br />
=== Python Wheels ===<br />
<br />
<br />
<br />
As far as wheels are concerned, in addition to building them, it is also necessary to upload them to [https://pypi.org/ PyPi] ("publish" them), so that they are available for [https://pypi.org/project/pip pip] installation.<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-releaser.yml <code>LuxCore Wheels Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-publisher.yml <code>LuxCore Wheels Publisher</code>]<br />
<br />
''Prerequisite: you must have released a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.''<br />
<br />
=== Samples ===<br />
<br />
As we plan to replace Samples by equivalent Python tools and thus deprecate them, the workflow has been limited to the Release part (no publish).<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/sample-releaser.yml <code>LuxCore Samples Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
=== BlendLuxCore ===<br />
<br />
<i>TODO</i><br />
<br />
= Version Management =<br />
<br />
== Semantic Versioning ==<br />
<br />
Starting for LuxCore version 2.10.0, we require that LuxCoreRender applies [https://semver.org/ Semantic Versioning]. Please strictly enforce this rule when incrementing version numbers.<br />
<br />
Remark: component versions does not have to be synced. For instance, in strict application of the standard, the newly created LuxCoreDeps will start at 1.0.0, while at the same time LuxCore is already at 2.10.0<br />
<br />
== Dependency Version pointer ==<br />
<br />
To make LuxCore know which version of dependencies it must be built against, we use a pointer.<br />
<br />
This pointer is stored in the file <code>build-helpers/build-settings.json</code>, under the path <code>Dependencies/release</code>.<br />
<br />
Make sure you keep it up-to-date when you upgrade LuxCore components.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender&diff=2679Building LuxCoreRender2026-04-24T04:12:42Z<p>Howetuft: /* Caveats */</p>
<hr />
<div>This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.<br />
<br />
LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all [[Building_LuxCoreRender_(legacy)|previous documents]] related to the compilation of older versions (<=2.9).<br />
<br />
<br />
<b>TL;DR</b> If you are just interested in a quick, local (but platform limited) compilation of LuxCore C++ samples or Python wheels, you may want to jump directly to [[#Build LuxCore, Samples & Python Wheels | Build LuxCore, Samples & Python Wheels]].</br><br />
<br />
<br />
<br />
= Audience =<br />
<br />
This document is intended for:<br />
* LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;<br />
* Developers wishing to contribute to the project;<br />
* External package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;<br />
<br />
This document assumes that the reader is skilled in the following areas:<br />
* C/C++ compilation<br />
* [https://cmake.org/ cmake]<br />
* [https://git-scm.com/ git]<br />
* [https://docs.github.com/en/actions/writing-workflows Github Workflows]<br />
* [https://packaging.python.org/en/latest/ Python Packaging], including [https://realpython.com/python-wheels/ Python Wheels format]<br />
<br />
Familiarity with [https://conan.io/ Conan] dependency manager may also help.<br />
<br />
</br><br />
This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries on the official [https://luxcorerender.org/download/ Download] page.<br />
<br />
= Build Targets =<br />
<br />
== Synoptic ==<br />
LuxCoreRender contains several build targets, below represented with dependency links:<br />
<br />
{{#mermaid:<br />
%%{<br />
init: {<br />
"theme": "forest",<br />
"logLevel": "info",<br />
"flowchart": {"curve": "basis"}<br />
}<br />
}%%<br />
<br />
flowchart LR;<br />
<br />
<br />
classDef TYPE font-weight:bold,font-size:1.1rem;<br />
classDef TARGET font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCOREDEPS fill:#ffe8ff,stroke:#9488af,font-weight:bold,font-size:1.1rem;<br />
classDef TARGETDEPS fill:#e4d8ff,stroke:#9488af,font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCORE fill:#bbceff,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETLUXCORE fill:#7799ee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef SAMPLES fill:#ffffdd,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETSAMPLES fill:#eeeecc,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef NEUTRAL fill:#fafafa,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETNEUTRAL fill:#eeeeee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef EXTDEP fill:#00000000,stroke:#00000000;<br />
<br />
<br />
subgraph Dependencies[External Dependencies]<br />
deps(LuxCore Dependencies)<br />
end<br />
<br />
class Dependencies LUXCOREDEPS;<br />
class deps TARGETDEPS;<br />
<br />
<br />
subgraph LuxCore<br />
lux(luxcore.so/.dll)<br />
luxa(luxcore.a)<br />
end<br />
class LuxCore LUXCORE;<br />
class lux TARGETLUXCORE;<br />
class luxa TARGETLUXCORE;<br />
<br />
subgraph Python_Wheels[Python Wheels]<br />
pylux(pyluxcore.so/.dll)<br />
wheels(LuxCore Python Wheels)<br />
end<br />
class Python_Wheels TYPE;<br />
class pylux TARGET;<br />
class wheels TARGET;<br />
<br />
subgraph Samples<br />
luxcoreui(luxcoreui)<br />
luxcoreconsole(luxcoreconsole)<br />
end<br />
class Samples SAMPLES;<br />
class luxcoreui TARGETSAMPLES;<br />
class luxcoreconsole TARGETSAMPLES;<br />
<br />
<br />
subgraph PyLuxCoreTools<br />
pyluxcon(pyluxcoreconsole)<br />
pyluxothers(...)<br />
end<br />
class PyLuxCoreTools NEUTRAL;<br />
class pyluxcon TARGETNEUTRAL;<br />
class pyluxothers TARGETNEUTRAL;<br />
<br />
subgraph Plugins[Python Plugins]<br />
blc(BlendLuxCore)<br />
otherplugins(...)<br />
end<br />
class blc TARGETNEUTRAL;<br />
class otherplugins TARGETNEUTRAL;<br />
<br />
class Plugins NEUTRAL;<br />
<br />
%% Warning: order matters<br />
deps-->lux<br />
deps-->luxa<br />
deps-->luxcoreui<br />
deps-->luxcoreconsole<br />
<br />
luxa--->pylux<br />
lux-->luxcoreui<br />
lux-->luxcoreconsole<br />
deps-->pylux<br />
<br />
<br />
<br />
pylux-->wheels<br />
wheels-. runtime .->blc<br />
wheels-. runtime .->otherplugins<br />
<br />
wheels-. runtime .->pyluxcon<br />
wheels-. runtime .->pyluxothers<br />
<br />
Python:::EXTDEP-->pylux<br />
<br />
<br />
%% Mermaid version: 8.14.0<br />
%% https://github.com/mermaid-js/mermaid/blob/8.14.0/src/defaultConfig.js<br />
<br />
<br />
<br />
}}<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! Target !! Source Repository !! Content<br />
|-<br />
| <b>External Dependencies</b>|| [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreDeps</code>] || A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to [https://github.com/LuxCoreRender/LuxCoreDeps/blob/main/README.md LuxCoreDeps README] for more information.<br />
|-<br />
| <b>LuxCore</b> || [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.<br />
|-<br />
| <b>Samples</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Sample C++ programs, illustrating luxcore use, namely <code>luxcoreconsole</code> and <code>luxcoreui</code><br />
|-<br />
| <b>Python Wheels</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version).</br> As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).<br />
|-<br />
| <b>Python Plugins</b>|| [https://github.com/LuxCoreRender/BlendLuxCore <code>BlendLuxCore</code>] etc. || Plugins to expose LuxCore in various external applications, notably Blender. </br> Written in Python and relying on Python Wheels as runtime dependency.<br />
|-<br />
| <b>PyLuxCoreTools</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python LuxCore Tools: set of command line tools based on pyluxcore, written in Python.<br />
|}<br />
<br />
== Targeted platforms ==<br />
<br />
LuxCoreRender aims at being available on the following 4 platforms:<br />
* Linux (glibc 2.28+)<br />
* Windows<br />
* MacOS Intel (>=10.15)<br />
* MacOS Arm (>=12.0)<br />
<br />
For Python-related targets, LuxCoreRender aims at being declined for [https://devguide.python.org/versions all Python versions supported at a given time].<br />
<br />
= Workflow Types =<br />
<br />
We distinguish between two types of build workflows:<br />
* Developer workflows<br />
* Publisher workflows<br />
<br />
<br />
''[[#Developer Workflows | Developer workflows]]'' are designed for development, debugging and test steps.<br />
<br />
Their purpose is to allow development and verify the code is ready for publication.<br />
<br />
<br />
''[[#Publisher Workflows | Publisher workflows]]'' are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.<br />
<br />
They exclusively take place in a CI/CD Github pipeline.<br />
<br />
These workflows are not designed for debugging or testing the underlying code. Execution of these workflows assumes that the development phase has been correctly completed and the underlying code is ready for final build and release. See [[#Developer Workflows | Developer Workflows]] to learn how to get code ready for final build.<br />
<br />
Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.<br />
<br />
= Developer Workflows =<br />
<br />
<br />
== Prerequisites ==<br />
<br />
<u>Tools</u><br />
<br />
You will need several build tools installed and referenced in the PATH.<br />
<br />
First, ensure you have a suitable toolchain:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! OS !! Compiler !! Minimal version<br />
|-<br />
| Windows || MSVC || 194x latest version<br />
|-<br />
| Linux|| gcc || 14<br />
|-<br />
| MacOS Intel|| XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|-<br />
| MacOS Arm || XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|}<br />
<br />
''Toolchain compliance is a very sensitive condition for a successful build. Before filing any claim, please check that your toolchain complies with the above requirements.''<br />
<br />
<br />
<br />
Then ensure the following software is also installed and available in your PATH:<br />
<br />
* [https://git-scm.com/ Git]<br />
* [https://cli.github.com/ Github CLI] (optional but recommended - for dependency signature checking)<br />
* [https://www.python.org/ Python 3] - any [https://devguide.python.org/versions/ currently supported version]<br />
* [https://conan.io Conan] latest version (pip install conan)<br />
* [https://github.com/pypa/wheel/tree/main Wheel] latest version (pip install wheel)<br />
* [https://cmake.org/ CMake] >= 3.29<br />
* [https://github.com/nektos/act nektos/act] (optional but recommended - for local build based on Github workflows)<br />
* [https://pypi.org/project/repairwheel repairwheel] (optional but recommended - for local build of test wheels)<br />
<br />
<br />
Platform specifics:<br />
* For Windows, ensure the command line is configured for building (<code>vcvarsall.bat</code>).<br />
* For Linux, you'll need <code>pkgconfig</code> in addition.<br />
* For MacOS, you'll need to ensure CC and CXX point to LLVM clang/clang++<br />
<br />
<u>Accounts</u><br />
<br />
A ''Github account'' is mandatory for LuxCore development.<br />
<br />
Following accounts are also recommended, in order to get in touch with LuxCore community:<br />
* [https://forums.luxcorerender.org/ LuxCoreRender Forums]<br />
* [https://discord.gg/chPGsKV LuxCoreRender Discord channel]<br />
<br />
== General Developer Workflow ==<br />
<br />
To compile and verify LuxCore component modifications in development process, there are 3 stages:<br />
* Local plain build: only run build system (cmake) on developer computer<br />
* Local Continuous Integration build: run full Continuous Integration workflow on developer computer<br />
* Server Continuous Integration build: run full Continuous Integration workflow on server<br />
<br />
<i>Local plain build</i> is generally faster than other builds and does not require to commit changes beforehand. Plain build installs a minimal build configuration (dependencies), but heavily relies on computer build environment for the rest (build tools, system libraries etc.). As a counterpart, it builds only for the platform where it is executed and can be significantly altered by local conditions (build tools local versions, dependency local versions etc.), thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<i>LocalCI </i> is generally faster than Server build, but slower than local plain build. CI workflow installs a complete build environment (compilers, sdk, build tools, containers, dependencies etc.) before running build system. It does not require to commit changes beforehand. However, it builds only for the platform where it is executed, thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<I>Server CI</i>, if successful, should guarantee success when publishing, as it occurs in conditions similar to release workflow (all platforms, complete build environment). As a counterpart, it is generally significantly slower than local builds and also implies to commit and push changes beforehand, even if the code is in unstable state.<br />
<br />
The recommended workflow thus strives to make the most of all stages:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
<br />
flowchart TD;<br />
<br />
fork(Fork Source repository in your own Github space)<br />
clone("Clone your fork locally</br><code>git clone...</code>")<br />
devel(Make modifications in your local fork)<br />
localBuild("<b>Run local plain build</b></br><code>cmake</code>, <code>make</code>...")<br />
localCI("<b>Run local CI</b></br><code>act</code>")<br />
git("Commit, Rebase & Push</br><code>git ...</code>")<br />
serverCI(<b>Run server CI</b></br><code>Github workflow</code>)<br />
PR(PR your changes to Source repository)<br />
<br />
fork-->clone<br />
clone-->devel<br />
devel-->localBuild<br />
localBuild-->localCI<br />
localCI-- "<i>Success</br>(including debug & tests)</i>" -->git<br />
git-->serverCI<br />
serverCI-- <i>Success</i> -->PR<br />
<br />
localBuild & localCI & serverCI ----> |<i>Failure</i>| devel<br />
<br />
classDef BUILD fill:#acc,stroke-width:4px;<br />
class localBuild BUILD;<br />
class localCI BUILD;<br />
class serverCI BUILD;<br />
<br />
}}<br />
<br />
This is the common process between all components. Each step will then be adapted to each component, as explained below.<br />
<br />
Comments:<br />
* Running local CI relies on [https://github.com/nektos/act <code>nektos/act</code>]<br />
* Rebase must be made against upstream directory (<code>git pull --rebase upstream <branch></code>)before pushing<br />
* Push must be made towards developer own fork. Caveat: do not try to push directly to upstream<br />
<br />
<br />
== Build External Dependencies ==<br />
<br />
=== Local Plain Build ===<br />
==== Caveats ====<br />
Dependency local plain build is possible but:<br />
* Local plain build IS NOT THE RECOMMENDED BUILD for final deps. This build is solely intended for intermediary development and debugging. No support will be provided when used out-of-scope.<br />
* Local plain build has only be tested on Linux, with gcc >=14. For other platforms, adaptations should be necessary (contributions welcome). <br />
* Local plain build is much impacted by local particulars (local compiler version, dependencies already in cache or in system dirs etc.) and therefore does not guarantee further success for other (recommended) builds.<br />
<br />
==== Prerequisites ====<br />
In addition with general [[#Prerequisites_2 | Prerequisites]], you'll need oneAPI ISPC compiler.<br />
<br />
==== Conan cache interaction ====<br />
<br />
The build relies on the local Conan cache, which will be modified by the process. You may want to make a copy beforehand.<br />
<br />
In some scenarios, you may also want to reset your Conan cache (warning: may remove files unrelated to LuxCoreDeps):<br />
<pre>conan remove -c "*" # Be careful: may remove packages unrelated to LuxCoreDeps!</pre><br />
<br />
==== Run ====<br />
<br />
To run a plain local build, run the following statements in a console, from the root of LuxCoreDeps repository:<br />
<br />
<pre><br />
export RUNNER_OS=<os><br />
export RUNNER_ARCH=<arch><br />
<br />
export LUXDEPS_VERSION=test<br />
export GCC_VERSION=14 # Note: even for gcc > 14<br />
export WORKSPACE=.<br />
export CXX_VERSION=20<br />
export CMAKE_POLICY_VERSION_MINIMUM=3.25<br />
export cache_dir<br />
<br />
./run_conan.sh<br />
</pre><br />
<br />
with <code>RUNNER_OS</code>, <code>RUNNER_ARCH</code> in:<br />
* <code>Linux</code> / <code>X64</code><br />
* <code>Windows</code> / <code>X64</code><br />
* <code>macOS</code> / <code>X64</code><br />
* <code>macOS</code> / <code>ARM64</code><br />
reflecting your build platform.<br />
<br />
No detection is made (compiler, OS, arch...) . You'll have to do it on your own and set environment variables accordingly.<br />
<br />
==== Cleaning ====<br />
<br />
Conan will produce a bunch of scripts in the root of LuxCoreDeps repo. You can clean them with the following:<br />
<pre> ./utils/clean-conan-files.sh </pre><br />
<br />
=== Local Continuous Integration ===<br />
<br />
Run <code>act</code> on workflows located in <code>.github/workflows</code> folder, for instance <code>.github/workflows/build.yml</code> workflow.</br><br />
<br />
For more convenience, a wrapper script is also provided in <code>LuxCoreDeps</code> repository (Linux only, at the moment): <pre>./utils/local-CI-build.sh</pre><br />
<br />
=== Server Continuous Integration ===<br />
<br />
This process relies on the following Github workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/checker.yml <code>LuxCore Dependency Checker</code>].<br />
</br>Important points:<br />
* Your changes must have been committed and pushed to repository before.<br />
* The Checker workflow is actually also triggered on push event, so you may not have to run it by yourself<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
== Build LuxCore, Samples & Python Wheels ==<br />
<br />
=== Local Plain Build ===<br />
<br />
==== Prerequisites ====<br />
<br />
First, we will assume you have correctly completed the [[#Prerequisites_2 | Prerequisites]]. <br />
<br />
Second, we will also assume you've already git-cloned LuxCore on your local machine, opened a terminal, changed directory to LuxCore folder and git-checked out the branch that you want to build (+ for Windows: initialized build environment with <code>vcvarsall.bat</code>)<br />
<br />
==== Basic build ====<br />
<br />
Our build system internally relies on <code>cmake</code> but, for more convenience, everything has been wrapped into <code>make</code>-like statements.<br />
<br />
So, to build LuxCore, one just have to enter the following magic words:<br />
<pre><br />
make deps<br />
make<br />
</pre><br />
<br />
This should retrieve and install LuxCore dependencies, configure the project and run the build. That's all!<br />
<br />
<br />
For subsequent builds, if no modification have been made to dependencies, you'll just have to re-enter: <pre>make</pre><br />
<br />
==== Specific targets ====<br />
<br />
If you want to target a specific component, you can replace the above plain <code>make</code> by one of the following verbs:<br />
<pre>make luxcore</pre><br />
<pre>make pyluxcore</pre><br />
<pre>make luxcoreui</pre><br />
<pre>make luxcoreconsole</pre><br />
<br />
<br />
Starting from version 2.11, this method can build a "test wheel". This is a simplified wheel, only for current platform and current Python version, for testing purpose. The test wheel is particularly useful for developing/debugging LuxCore/BlendLuxCore integration.<br />
The verb is:<br />
<pre>make wheel-test</pre><br />
<br />
<br />
You can also build Doxygen documentation with the following statement:<br />
<pre>make doc</pre><br />
<br />
==== Build type ====<br />
<br />
By default, this method builds a release version, striped from all symbols. If you want to build a debug version, enter the following before any <code>make ...</code> command:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug</pre> <br />
<br />
==== Local dependency set ====<br />
<br />
It is possible to use a local dependency set, rather than relying on automatic downloading. It is especially useful for developing/debugging of LuxCoreDeps/LuxCore integration. In this case, one can replace the <code>make deps</code> statement by the following one:<br />
<br />
<pre><br />
python -m build-system.luxmake.deps --local <path/to/local/deps> --release <release><br />
</pre><br />
<br />
Nota: <code><release></code> is the release tag used by your local dependency set. If you build this set locally, it should likely be <code>test</code>.<br />
<br />
==== Cleaning ====<br />
<br />
You can remove build outputs with one of the following statement:<br />
<pre>make clean</pre><br />
or<br />
<pre>make clear</pre><br />
The former will remove build files, however preserving dependencies. <br />
The latter will remove everything and will require to reinstall dependencies (<code>make deps</code>).<br />
<br />
=== Local Continuous Integration ===<br />
<br />
This method is complementary to Local plain build, with the following additional capabilities:<br />
* test the LuxCore build in an environment close to the release environment (manylinux container, for instance)<br />
* can build wheels<br />
* debug any changes made to the build workflow<br />
<br />
It consists in running Github workflows locally, via <code>act</code>. Github workflows are located in <code>.github/workflows</code> folder.<br />
<br />
<code>act</code> invokation can be made on command line but, for convenience, a wrapper script is provided (for Linux): <pre>./build-helpers/debug/debug_wheels.sh</pre><br />
<br />
<i>Caveat: this build can produce wheels, but only for the host platform (no cross-compiling).</i><br />
<br />
=== Server Continuous Integration ===<br />
<br />
The process is nearly the same as publisher build, but the release steps are skipped. For that purpose, another Github workflow has to be executed: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-builder.yml <code>LuxCore Python Wheels Builder</code>].<br />
<br />
Please note that your changes must have been committed to repository before running the workflow.<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
= Publisher Workflows =<br />
<br />
== Prerequisites ==<br />
<br />
For these workflows, a Github account is required, with extended rights on the source repositories.<br />
<br />
== General Workflow ==<br />
<br />
The general workflow for publishing is in 3 parts:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
flowchart TD;<br />
subgraph Build["<center><b>BUILD & RELEASE DRAFT </br>(Run Releaser workflow)</b></center>"]<br />
padBuild(" "):::INVISIBLE<br />
repo("Go to <code>[Source repository]</code> on Github and open <code>Actions menu</code>")<br />
select("Select <code>[Releaser workflow]</code>")<br />
runwf(Click on <code>Run workflow</code> button, in the upper-right corner)<br />
branch(Select <code>Branch</code> in drop-down menu)<br />
options(Set workflow options)<br />
validate(Click <code>Run workflow</code>)<br />
wait(Wait for build to complete)<br />
end<br />
<br />
subgraph Release["<center><b>MAKE FINAL RELEASE</br>(Switch release to final status)</b></center>"]<br />
padRelease(" "):::INVISIBLE<br />
release("Open <code>[Release folder]</code>,</br> find the newly-built release (in Draft mode) </br> and edit it")<br />
complete(Add relevant information: change log, comments on version etc.)<br />
dedraft(Unset <code>Draft</code> checkbox)<br />
update(Click <code>Publish release</code>/<code>Update release</code> to finalize)<br />
end<br />
<br />
subgraph Deploy["<center><b>PUBLISH</br>(Run Publisher workflow)</b></center>"]<br />
padDeploy(" ")<br />
repoDeploy("Go to <code>[Source repository]</code> on Github and open <code>[Actions menu]</code>")<br />
selectDeploy("Select <code>[Publisher workflow]</code>")<br />
runwfDeploy("Click on <code>Run workflow</code> drop-down button, in the upper-right corner")<br />
choiceDeploy("Select <code>Branch</code>, set the <code>Tag to publish</code> and uncheck <code>Publish on Pypi Test</code> if needed")<br />
validateDeploy("Click on <code>Run workflow</code> button")<br />
waitDeploy("Wait for deployment to complete")<br />
end<br />
<br />
padBuild---repo<br />
repo-->select<br />
select-->runwf<br />
runwf-->branch<br />
branch-->options<br />
options-->validate<br />
validate-->wait:::WAIT<br />
linkStyle 0 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padRelease---release<br />
release-->complete<br />
complete-->dedraft<br />
dedraft-->update<br />
linkStyle 7 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padDeploy:::INVISIBLE---repoDeploy<br />
repoDeploy-->selectDeploy<br />
selectDeploy-->runwfDeploy<br />
runwfDeploy-->choiceDeploy<br />
choiceDeploy-->validateDeploy<br />
validateDeploy-->waitDeploy:::WAIT<br />
linkStyle 11 stroke:#fff,color:blue,stroke-width:0px;<br />
<br />
<br />
Build-- <i>if success</i> -->Release<br />
Release-- <i>if success & if needed</i> -->Deploy<br />
<br />
classDef WAIT fill:#ddd;<br />
classDef DEPS fill:#e4d8ff,stroke:#9488af;<br />
classDef INVISIBLE fill:#ffffffff,stroke:#ffffffff,stroke-width:0px,font-color:#ffffffff;<br />
classDef OPTIONAL stroke-dasharray: 5 5;<br />
<br />
class Deploy OPTIONAL;<br />
<br />
%% Note: padXXX is a poor hack to create a top-margin in subgraph...<br />
}}<br />
<br />
A few comments:<br />
* <code>[bracketed tokens]</code> refer to data specific to each component, which will be detailed below.<br />
* Publish part is optional, it will depends on the target<br />
* ''Caveat: if you provide an already-existing release version number during the process, the workflow will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.''<br />
<br />
== Per-target details ==<br />
<br />
=== External Dependencies ===<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreRender/LuxCoreDeps</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/release.yml <code>LuxCore Dependency Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCoreDeps/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
As a byproduct, External Dependencies are not intended to be deployed, so no Publisher workflow is provided.<br />
<br />
=== Python Wheels ===<br />
<br />
<br />
<br />
As far as wheels are concerned, in addition to building them, it is also necessary to upload them to [https://pypi.org/ PyPi] ("publish" them), so that they are available for [https://pypi.org/project/pip pip] installation.<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-releaser.yml <code>LuxCore Wheels Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-publisher.yml <code>LuxCore Wheels Publisher</code>]<br />
<br />
''Prerequisite: you must have released a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.''<br />
<br />
=== Samples ===<br />
<br />
As we plan to replace Samples by equivalent Python tools and thus deprecate them, the workflow has been limited to the Release part (no publish).<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/sample-releaser.yml <code>LuxCore Samples Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
=== BlendLuxCore ===<br />
<br />
<i>TODO</i><br />
<br />
= Version Management =<br />
<br />
== Semantic Versioning ==<br />
<br />
Starting for LuxCore version 2.10.0, we require that LuxCoreRender applies [https://semver.org/ Semantic Versioning]. Please strictly enforce this rule when incrementing version numbers.<br />
<br />
Remark: component versions does not have to be synced. For instance, in strict application of the standard, the newly created LuxCoreDeps will start at 1.0.0, while at the same time LuxCore is already at 2.10.0<br />
<br />
== Dependency Version pointer ==<br />
<br />
To make LuxCore know which version of dependencies it must be built against, we use a pointer.<br />
<br />
This pointer is stored in the file <code>build-helpers/build-settings.json</code>, under the path <code>Dependencies/release</code>.<br />
<br />
Make sure you keep it up-to-date when you upgrade LuxCore components.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender&diff=2678Building LuxCoreRender2026-04-24T04:12:33Z<p>Howetuft: /* Caveats */</p>
<hr />
<div>This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.<br />
<br />
LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all [[Building_LuxCoreRender_(legacy)|previous documents]] related to the compilation of older versions (<=2.9).<br />
<br />
<br />
<b>TL;DR</b> If you are just interested in a quick, local (but platform limited) compilation of LuxCore C++ samples or Python wheels, you may want to jump directly to [[#Build LuxCore, Samples & Python Wheels | Build LuxCore, Samples & Python Wheels]].</br><br />
<br />
<br />
<br />
= Audience =<br />
<br />
This document is intended for:<br />
* LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;<br />
* Developers wishing to contribute to the project;<br />
* External package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;<br />
<br />
This document assumes that the reader is skilled in the following areas:<br />
* C/C++ compilation<br />
* [https://cmake.org/ cmake]<br />
* [https://git-scm.com/ git]<br />
* [https://docs.github.com/en/actions/writing-workflows Github Workflows]<br />
* [https://packaging.python.org/en/latest/ Python Packaging], including [https://realpython.com/python-wheels/ Python Wheels format]<br />
<br />
Familiarity with [https://conan.io/ Conan] dependency manager may also help.<br />
<br />
</br><br />
This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries on the official [https://luxcorerender.org/download/ Download] page.<br />
<br />
= Build Targets =<br />
<br />
== Synoptic ==<br />
LuxCoreRender contains several build targets, below represented with dependency links:<br />
<br />
{{#mermaid:<br />
%%{<br />
init: {<br />
"theme": "forest",<br />
"logLevel": "info",<br />
"flowchart": {"curve": "basis"}<br />
}<br />
}%%<br />
<br />
flowchart LR;<br />
<br />
<br />
classDef TYPE font-weight:bold,font-size:1.1rem;<br />
classDef TARGET font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCOREDEPS fill:#ffe8ff,stroke:#9488af,font-weight:bold,font-size:1.1rem;<br />
classDef TARGETDEPS fill:#e4d8ff,stroke:#9488af,font-weight:bold,font-size:0.9rem;<br />
<br />
classDef LUXCORE fill:#bbceff,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETLUXCORE fill:#7799ee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef SAMPLES fill:#ffffdd,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETSAMPLES fill:#eeeecc,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef NEUTRAL fill:#fafafa,font-weight:bold,font-size:1.1rem,stroke:#999999;<br />
classDef TARGETNEUTRAL fill:#eeeeee,font-weight:bold,font-size:0.9rem,stroke:#999999;<br />
<br />
classDef EXTDEP fill:#00000000,stroke:#00000000;<br />
<br />
<br />
subgraph Dependencies[External Dependencies]<br />
deps(LuxCore Dependencies)<br />
end<br />
<br />
class Dependencies LUXCOREDEPS;<br />
class deps TARGETDEPS;<br />
<br />
<br />
subgraph LuxCore<br />
lux(luxcore.so/.dll)<br />
luxa(luxcore.a)<br />
end<br />
class LuxCore LUXCORE;<br />
class lux TARGETLUXCORE;<br />
class luxa TARGETLUXCORE;<br />
<br />
subgraph Python_Wheels[Python Wheels]<br />
pylux(pyluxcore.so/.dll)<br />
wheels(LuxCore Python Wheels)<br />
end<br />
class Python_Wheels TYPE;<br />
class pylux TARGET;<br />
class wheels TARGET;<br />
<br />
subgraph Samples<br />
luxcoreui(luxcoreui)<br />
luxcoreconsole(luxcoreconsole)<br />
end<br />
class Samples SAMPLES;<br />
class luxcoreui TARGETSAMPLES;<br />
class luxcoreconsole TARGETSAMPLES;<br />
<br />
<br />
subgraph PyLuxCoreTools<br />
pyluxcon(pyluxcoreconsole)<br />
pyluxothers(...)<br />
end<br />
class PyLuxCoreTools NEUTRAL;<br />
class pyluxcon TARGETNEUTRAL;<br />
class pyluxothers TARGETNEUTRAL;<br />
<br />
subgraph Plugins[Python Plugins]<br />
blc(BlendLuxCore)<br />
otherplugins(...)<br />
end<br />
class blc TARGETNEUTRAL;<br />
class otherplugins TARGETNEUTRAL;<br />
<br />
class Plugins NEUTRAL;<br />
<br />
%% Warning: order matters<br />
deps-->lux<br />
deps-->luxa<br />
deps-->luxcoreui<br />
deps-->luxcoreconsole<br />
<br />
luxa--->pylux<br />
lux-->luxcoreui<br />
lux-->luxcoreconsole<br />
deps-->pylux<br />
<br />
<br />
<br />
pylux-->wheels<br />
wheels-. runtime .->blc<br />
wheels-. runtime .->otherplugins<br />
<br />
wheels-. runtime .->pyluxcon<br />
wheels-. runtime .->pyluxothers<br />
<br />
Python:::EXTDEP-->pylux<br />
<br />
<br />
%% Mermaid version: 8.14.0<br />
%% https://github.com/mermaid-js/mermaid/blob/8.14.0/src/defaultConfig.js<br />
<br />
<br />
<br />
}}<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! Target !! Source Repository !! Content<br />
|-<br />
| <b>External Dependencies</b>|| [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreDeps</code>] || A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to [https://github.com/LuxCoreRender/LuxCoreDeps/blob/main/README.md LuxCoreDeps README] for more information.<br />
|-<br />
| <b>LuxCore</b> || [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.<br />
|-<br />
| <b>Samples</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Sample C++ programs, illustrating luxcore use, namely <code>luxcoreconsole</code> and <code>luxcoreui</code><br />
|-<br />
| <b>Python Wheels</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version).</br> As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).<br />
|-<br />
| <b>Python Plugins</b>|| [https://github.com/LuxCoreRender/BlendLuxCore <code>BlendLuxCore</code>] etc. || Plugins to expose LuxCore in various external applications, notably Blender. </br> Written in Python and relying on Python Wheels as runtime dependency.<br />
|-<br />
| <b>PyLuxCoreTools</b>|| [https://github.com/LuxCoreRender/LuxCore <code>LuxCore</code>] || Python LuxCore Tools: set of command line tools based on pyluxcore, written in Python.<br />
|}<br />
<br />
== Targeted platforms ==<br />
<br />
LuxCoreRender aims at being available on the following 4 platforms:<br />
* Linux (glibc 2.28+)<br />
* Windows<br />
* MacOS Intel (>=10.15)<br />
* MacOS Arm (>=12.0)<br />
<br />
For Python-related targets, LuxCoreRender aims at being declined for [https://devguide.python.org/versions all Python versions supported at a given time].<br />
<br />
= Workflow Types =<br />
<br />
We distinguish between two types of build workflows:<br />
* Developer workflows<br />
* Publisher workflows<br />
<br />
<br />
''[[#Developer Workflows | Developer workflows]]'' are designed for development, debugging and test steps.<br />
<br />
Their purpose is to allow development and verify the code is ready for publication.<br />
<br />
<br />
''[[#Publisher Workflows | Publisher workflows]]'' are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.<br />
<br />
They exclusively take place in a CI/CD Github pipeline.<br />
<br />
These workflows are not designed for debugging or testing the underlying code. Execution of these workflows assumes that the development phase has been correctly completed and the underlying code is ready for final build and release. See [[#Developer Workflows | Developer Workflows]] to learn how to get code ready for final build.<br />
<br />
Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.<br />
<br />
= Developer Workflows =<br />
<br />
<br />
== Prerequisites ==<br />
<br />
<u>Tools</u><br />
<br />
You will need several build tools installed and referenced in the PATH.<br />
<br />
First, ensure you have a suitable toolchain:<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|-<br />
! OS !! Compiler !! Minimal version<br />
|-<br />
| Windows || MSVC || 194x latest version<br />
|-<br />
| Linux|| gcc || 14<br />
|-<br />
| MacOS Intel|| XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|-<br />
| MacOS Arm || XCode + llvm + libomp || llvm >= 20 <br> (<code>brew install llvm && brew install libomp</code>)<br />
|}<br />
<br />
''Toolchain compliance is a very sensitive condition for a successful build. Before filing any claim, please check that your toolchain complies with the above requirements.''<br />
<br />
<br />
<br />
Then ensure the following software is also installed and available in your PATH:<br />
<br />
* [https://git-scm.com/ Git]<br />
* [https://cli.github.com/ Github CLI] (optional but recommended - for dependency signature checking)<br />
* [https://www.python.org/ Python 3] - any [https://devguide.python.org/versions/ currently supported version]<br />
* [https://conan.io Conan] latest version (pip install conan)<br />
* [https://github.com/pypa/wheel/tree/main Wheel] latest version (pip install wheel)<br />
* [https://cmake.org/ CMake] >= 3.29<br />
* [https://github.com/nektos/act nektos/act] (optional but recommended - for local build based on Github workflows)<br />
* [https://pypi.org/project/repairwheel repairwheel] (optional but recommended - for local build of test wheels)<br />
<br />
<br />
Platform specifics:<br />
* For Windows, ensure the command line is configured for building (<code>vcvarsall.bat</code>).<br />
* For Linux, you'll need <code>pkgconfig</code> in addition.<br />
* For MacOS, you'll need to ensure CC and CXX point to LLVM clang/clang++<br />
<br />
<u>Accounts</u><br />
<br />
A ''Github account'' is mandatory for LuxCore development.<br />
<br />
Following accounts are also recommended, in order to get in touch with LuxCore community:<br />
* [https://forums.luxcorerender.org/ LuxCoreRender Forums]<br />
* [https://discord.gg/chPGsKV LuxCoreRender Discord channel]<br />
<br />
== General Developer Workflow ==<br />
<br />
To compile and verify LuxCore component modifications in development process, there are 3 stages:<br />
* Local plain build: only run build system (cmake) on developer computer<br />
* Local Continuous Integration build: run full Continuous Integration workflow on developer computer<br />
* Server Continuous Integration build: run full Continuous Integration workflow on server<br />
<br />
<i>Local plain build</i> is generally faster than other builds and does not require to commit changes beforehand. Plain build installs a minimal build configuration (dependencies), but heavily relies on computer build environment for the rest (build tools, system libraries etc.). As a counterpart, it builds only for the platform where it is executed and can be significantly altered by local conditions (build tools local versions, dependency local versions etc.), thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<i>LocalCI </i> is generally faster than Server build, but slower than local plain build. CI workflow installs a complete build environment (compilers, sdk, build tools, containers, dependencies etc.) before running build system. It does not require to commit changes beforehand. However, it builds only for the platform where it is executed, thus not fully guaranteeing that final publish workflow will succeed.<br />
<br />
<I>Server CI</i>, if successful, should guarantee success when publishing, as it occurs in conditions similar to release workflow (all platforms, complete build environment). As a counterpart, it is generally significantly slower than local builds and also implies to commit and push changes beforehand, even if the code is in unstable state.<br />
<br />
The recommended workflow thus strives to make the most of all stages:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
<br />
flowchart TD;<br />
<br />
fork(Fork Source repository in your own Github space)<br />
clone("Clone your fork locally</br><code>git clone...</code>")<br />
devel(Make modifications in your local fork)<br />
localBuild("<b>Run local plain build</b></br><code>cmake</code>, <code>make</code>...")<br />
localCI("<b>Run local CI</b></br><code>act</code>")<br />
git("Commit, Rebase & Push</br><code>git ...</code>")<br />
serverCI(<b>Run server CI</b></br><code>Github workflow</code>)<br />
PR(PR your changes to Source repository)<br />
<br />
fork-->clone<br />
clone-->devel<br />
devel-->localBuild<br />
localBuild-->localCI<br />
localCI-- "<i>Success</br>(including debug & tests)</i>" -->git<br />
git-->serverCI<br />
serverCI-- <i>Success</i> -->PR<br />
<br />
localBuild & localCI & serverCI ----> |<i>Failure</i>| devel<br />
<br />
classDef BUILD fill:#acc,stroke-width:4px;<br />
class localBuild BUILD;<br />
class localCI BUILD;<br />
class serverCI BUILD;<br />
<br />
}}<br />
<br />
This is the common process between all components. Each step will then be adapted to each component, as explained below.<br />
<br />
Comments:<br />
* Running local CI relies on [https://github.com/nektos/act <code>nektos/act</code>]<br />
* Rebase must be made against upstream directory (<code>git pull --rebase upstream <branch></code>)before pushing<br />
* Push must be made towards developer own fork. Caveat: do not try to push directly to upstream<br />
<br />
<br />
== Build External Dependencies ==<br />
<br />
=== Local Plain Build ===<br />
==== Caveats ====<br />
Dependeny local plain build is possible but:<br />
* Local plain build IS NOT THE RECOMMENDED BUILD for final deps. This build is solely intended for intermediary development and debugging. No support will be provided when used out-of-scope.<br />
* Local plain build has only be tested on Linux, with gcc >=14. For other platforms, adaptations should be necessary (contributions welcome). <br />
* Local plain build is much impacted by local particulars (local compiler version, dependencies already in cache or in system dirs etc.) and therefore does not guarantee further success for other (recommended) builds.<br />
<br />
==== Prerequisites ====<br />
In addition with general [[#Prerequisites_2 | Prerequisites]], you'll need oneAPI ISPC compiler.<br />
<br />
==== Conan cache interaction ====<br />
<br />
The build relies on the local Conan cache, which will be modified by the process. You may want to make a copy beforehand.<br />
<br />
In some scenarios, you may also want to reset your Conan cache (warning: may remove files unrelated to LuxCoreDeps):<br />
<pre>conan remove -c "*" # Be careful: may remove packages unrelated to LuxCoreDeps!</pre><br />
<br />
==== Run ====<br />
<br />
To run a plain local build, run the following statements in a console, from the root of LuxCoreDeps repository:<br />
<br />
<pre><br />
export RUNNER_OS=<os><br />
export RUNNER_ARCH=<arch><br />
<br />
export LUXDEPS_VERSION=test<br />
export GCC_VERSION=14 # Note: even for gcc > 14<br />
export WORKSPACE=.<br />
export CXX_VERSION=20<br />
export CMAKE_POLICY_VERSION_MINIMUM=3.25<br />
export cache_dir<br />
<br />
./run_conan.sh<br />
</pre><br />
<br />
with <code>RUNNER_OS</code>, <code>RUNNER_ARCH</code> in:<br />
* <code>Linux</code> / <code>X64</code><br />
* <code>Windows</code> / <code>X64</code><br />
* <code>macOS</code> / <code>X64</code><br />
* <code>macOS</code> / <code>ARM64</code><br />
reflecting your build platform.<br />
<br />
No detection is made (compiler, OS, arch...) . You'll have to do it on your own and set environment variables accordingly.<br />
<br />
==== Cleaning ====<br />
<br />
Conan will produce a bunch of scripts in the root of LuxCoreDeps repo. You can clean them with the following:<br />
<pre> ./utils/clean-conan-files.sh </pre><br />
<br />
=== Local Continuous Integration ===<br />
<br />
Run <code>act</code> on workflows located in <code>.github/workflows</code> folder, for instance <code>.github/workflows/build.yml</code> workflow.</br><br />
<br />
For more convenience, a wrapper script is also provided in <code>LuxCoreDeps</code> repository (Linux only, at the moment): <pre>./utils/local-CI-build.sh</pre><br />
<br />
=== Server Continuous Integration ===<br />
<br />
This process relies on the following Github workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/checker.yml <code>LuxCore Dependency Checker</code>].<br />
</br>Important points:<br />
* Your changes must have been committed and pushed to repository before.<br />
* The Checker workflow is actually also triggered on push event, so you may not have to run it by yourself<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
== Build LuxCore, Samples & Python Wheels ==<br />
<br />
=== Local Plain Build ===<br />
<br />
==== Prerequisites ====<br />
<br />
First, we will assume you have correctly completed the [[#Prerequisites_2 | Prerequisites]]. <br />
<br />
Second, we will also assume you've already git-cloned LuxCore on your local machine, opened a terminal, changed directory to LuxCore folder and git-checked out the branch that you want to build (+ for Windows: initialized build environment with <code>vcvarsall.bat</code>)<br />
<br />
==== Basic build ====<br />
<br />
Our build system internally relies on <code>cmake</code> but, for more convenience, everything has been wrapped into <code>make</code>-like statements.<br />
<br />
So, to build LuxCore, one just have to enter the following magic words:<br />
<pre><br />
make deps<br />
make<br />
</pre><br />
<br />
This should retrieve and install LuxCore dependencies, configure the project and run the build. That's all!<br />
<br />
<br />
For subsequent builds, if no modification have been made to dependencies, you'll just have to re-enter: <pre>make</pre><br />
<br />
==== Specific targets ====<br />
<br />
If you want to target a specific component, you can replace the above plain <code>make</code> by one of the following verbs:<br />
<pre>make luxcore</pre><br />
<pre>make pyluxcore</pre><br />
<pre>make luxcoreui</pre><br />
<pre>make luxcoreconsole</pre><br />
<br />
<br />
Starting from version 2.11, this method can build a "test wheel". This is a simplified wheel, only for current platform and current Python version, for testing purpose. The test wheel is particularly useful for developing/debugging LuxCore/BlendLuxCore integration.<br />
The verb is:<br />
<pre>make wheel-test</pre><br />
<br />
<br />
You can also build Doxygen documentation with the following statement:<br />
<pre>make doc</pre><br />
<br />
==== Build type ====<br />
<br />
By default, this method builds a release version, striped from all symbols. If you want to build a debug version, enter the following before any <code>make ...</code> command:<br />
<br />
<pre>export LUX_BUILD_TYPE=Debug</pre> <br />
<br />
==== Local dependency set ====<br />
<br />
It is possible to use a local dependency set, rather than relying on automatic downloading. It is especially useful for developing/debugging of LuxCoreDeps/LuxCore integration. In this case, one can replace the <code>make deps</code> statement by the following one:<br />
<br />
<pre><br />
python -m build-system.luxmake.deps --local <path/to/local/deps> --release <release><br />
</pre><br />
<br />
Nota: <code><release></code> is the release tag used by your local dependency set. If you build this set locally, it should likely be <code>test</code>.<br />
<br />
==== Cleaning ====<br />
<br />
You can remove build outputs with one of the following statement:<br />
<pre>make clean</pre><br />
or<br />
<pre>make clear</pre><br />
The former will remove build files, however preserving dependencies. <br />
The latter will remove everything and will require to reinstall dependencies (<code>make deps</code>).<br />
<br />
=== Local Continuous Integration ===<br />
<br />
This method is complementary to Local plain build, with the following additional capabilities:<br />
* test the LuxCore build in an environment close to the release environment (manylinux container, for instance)<br />
* can build wheels<br />
* debug any changes made to the build workflow<br />
<br />
It consists in running Github workflows locally, via <code>act</code>. Github workflows are located in <code>.github/workflows</code> folder.<br />
<br />
<code>act</code> invokation can be made on command line but, for convenience, a wrapper script is provided (for Linux): <pre>./build-helpers/debug/debug_wheels.sh</pre><br />
<br />
<i>Caveat: this build can produce wheels, but only for the host platform (no cross-compiling).</i><br />
<br />
=== Server Continuous Integration ===<br />
<br />
The process is nearly the same as publisher build, but the release steps are skipped. For that purpose, another Github workflow has to be executed: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-builder.yml <code>LuxCore Python Wheels Builder</code>].<br />
<br />
Please note that your changes must have been committed to repository before running the workflow.<br />
<br />
If build succeeds, you will find the expected outputs in Artifacts section of the action run.<br />
<br />
= Publisher Workflows =<br />
<br />
== Prerequisites ==<br />
<br />
For these workflows, a Github account is required, with extended rights on the source repositories.<br />
<br />
== General Workflow ==<br />
<br />
The general workflow for publishing is in 3 parts:<br />
<br />
{{#mermaid: <br />
<br />
%%{ init: {<br />
'theme': 'neutral',<br />
'flowchart': { 'curve': 'monotoneX' }<br />
}<br />
}%%<br />
flowchart TD;<br />
subgraph Build["<center><b>BUILD & RELEASE DRAFT </br>(Run Releaser workflow)</b></center>"]<br />
padBuild(" "):::INVISIBLE<br />
repo("Go to <code>[Source repository]</code> on Github and open <code>Actions menu</code>")<br />
select("Select <code>[Releaser workflow]</code>")<br />
runwf(Click on <code>Run workflow</code> button, in the upper-right corner)<br />
branch(Select <code>Branch</code> in drop-down menu)<br />
options(Set workflow options)<br />
validate(Click <code>Run workflow</code>)<br />
wait(Wait for build to complete)<br />
end<br />
<br />
subgraph Release["<center><b>MAKE FINAL RELEASE</br>(Switch release to final status)</b></center>"]<br />
padRelease(" "):::INVISIBLE<br />
release("Open <code>[Release folder]</code>,</br> find the newly-built release (in Draft mode) </br> and edit it")<br />
complete(Add relevant information: change log, comments on version etc.)<br />
dedraft(Unset <code>Draft</code> checkbox)<br />
update(Click <code>Publish release</code>/<code>Update release</code> to finalize)<br />
end<br />
<br />
subgraph Deploy["<center><b>PUBLISH</br>(Run Publisher workflow)</b></center>"]<br />
padDeploy(" ")<br />
repoDeploy("Go to <code>[Source repository]</code> on Github and open <code>[Actions menu]</code>")<br />
selectDeploy("Select <code>[Publisher workflow]</code>")<br />
runwfDeploy("Click on <code>Run workflow</code> drop-down button, in the upper-right corner")<br />
choiceDeploy("Select <code>Branch</code>, set the <code>Tag to publish</code> and uncheck <code>Publish on Pypi Test</code> if needed")<br />
validateDeploy("Click on <code>Run workflow</code> button")<br />
waitDeploy("Wait for deployment to complete")<br />
end<br />
<br />
padBuild---repo<br />
repo-->select<br />
select-->runwf<br />
runwf-->branch<br />
branch-->options<br />
options-->validate<br />
validate-->wait:::WAIT<br />
linkStyle 0 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padRelease---release<br />
release-->complete<br />
complete-->dedraft<br />
dedraft-->update<br />
linkStyle 7 stroke:#fff,stroke-width:0px,color:blue;<br />
<br />
padDeploy:::INVISIBLE---repoDeploy<br />
repoDeploy-->selectDeploy<br />
selectDeploy-->runwfDeploy<br />
runwfDeploy-->choiceDeploy<br />
choiceDeploy-->validateDeploy<br />
validateDeploy-->waitDeploy:::WAIT<br />
linkStyle 11 stroke:#fff,color:blue,stroke-width:0px;<br />
<br />
<br />
Build-- <i>if success</i> -->Release<br />
Release-- <i>if success & if needed</i> -->Deploy<br />
<br />
classDef WAIT fill:#ddd;<br />
classDef DEPS fill:#e4d8ff,stroke:#9488af;<br />
classDef INVISIBLE fill:#ffffffff,stroke:#ffffffff,stroke-width:0px,font-color:#ffffffff;<br />
classDef OPTIONAL stroke-dasharray: 5 5;<br />
<br />
class Deploy OPTIONAL;<br />
<br />
%% Note: padXXX is a poor hack to create a top-margin in subgraph...<br />
}}<br />
<br />
A few comments:<br />
* <code>[bracketed tokens]</code> refer to data specific to each component, which will be detailed below.<br />
* Publish part is optional, it will depends on the target<br />
* ''Caveat: if you provide an already-existing release version number during the process, the workflow will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.''<br />
<br />
== Per-target details ==<br />
<br />
=== External Dependencies ===<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCoreDeps <code>LuxCoreRender/LuxCoreDeps</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCoreDeps/actions/workflows/release.yml <code>LuxCore Dependency Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCoreDeps/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
As a byproduct, External Dependencies are not intended to be deployed, so no Publisher workflow is provided.<br />
<br />
=== Python Wheels ===<br />
<br />
<br />
<br />
As far as wheels are concerned, in addition to building them, it is also necessary to upload them to [https://pypi.org/ PyPi] ("publish" them), so that they are available for [https://pypi.org/project/pip pip] installation.<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-releaser.yml <code>LuxCore Wheels Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/wheel-publisher.yml <code>LuxCore Wheels Publisher</code>]<br />
<br />
''Prerequisite: you must have released a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.''<br />
<br />
=== Samples ===<br />
<br />
As we plan to replace Samples by equivalent Python tools and thus deprecate them, the workflow has been limited to the Release part (no publish).<br />
<br />
* Source repository: [https://github.com/LuxCoreRender/LuxCore <code>LuxCoreRender/LuxCore</code>]<br />
* Releaser workflow: [https://github.com/LuxCoreRender/LuxCore/actions/workflows/sample-releaser.yml <code>LuxCore Samples Releaser</code>]<br />
* Release folder: [https://github.com/LuxCoreRender/LuxCore/releases <code>Releases</code>]<br />
* Publisher workflow: ∅<br />
<br />
=== BlendLuxCore ===<br />
<br />
<i>TODO</i><br />
<br />
= Version Management =<br />
<br />
== Semantic Versioning ==<br />
<br />
Starting for LuxCore version 2.10.0, we require that LuxCoreRender applies [https://semver.org/ Semantic Versioning]. Please strictly enforce this rule when incrementing version numbers.<br />
<br />
Remark: component versions does not have to be synced. For instance, in strict application of the standard, the newly created LuxCoreDeps will start at 1.0.0, while at the same time LuxCore is already at 2.10.0<br />
<br />
== Dependency Version pointer ==<br />
<br />
To make LuxCore know which version of dependencies it must be built against, we use a pointer.<br />
<br />
This pointer is stored in the file <code>build-helpers/build-settings.json</code>, under the path <code>Dependencies/release</code>.<br />
<br />
Make sure you keep it up-to-date when you upgrade LuxCore components.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2677Building LuxCoreRender - FAQ2026-04-24T04:10:57Z<p>Howetuft: /* Can I generate debug information for dependencies (LuxCoreDeps)? */</p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local dependency build, at the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Building_LuxCoreRender_-_FAQ&diff=2676Building LuxCoreRender - FAQ2026-04-24T04:10:23Z<p>Howetuft: </p>
<hr />
<div>== Is it possible to set-up a local-only, end-to-end, build chain? ==<br />
<br />
Yes it is, but for Linux only, at the moment, and starting with v2.11.<br />
<p>Also, important caveat: this kind of build is solely intended for development and tests. Do not use in production</p><br />
<br />
<br />
* Step#1: Build dependencies locally<br />
<br />
Use [[Building_LuxCoreRender#Local_Plain_Build|local plain build]] or [[Building_LuxCoreRender#Local_Continuous_Integration | local CI build]] of LuxCoreDeps<br />
<br />
<br />
* Step#2: Inject local dependencies in LuxCore build<br />
<pre>python -m build-system.luxmake deps --local <path/to/deps> --release test</pre><br />
<br />
<br />
* Step#3: Build a testing wheel<br />
<pre>make wheel-test</pre><br />
<br />
<br />
<br />
* Step#4: Inject testing wheel in Blender:<br />
<br />
Use [[Developing_and_debugging_BlendLuxCore | BlendLuxHelper]]<br />
<br />
<br />
<br />
For a debugging with luxcoreui only, one can also replace steps #3 & #4 by:<br />
<br />
* Step#3bis: Build luxcoreui:<br />
<pre>make luxcoreui</pre><br />
<br />
== Can I use <code>git bisect</code>? ==<br />
<br />
Yes, if you need to find a faulty commit, you can use <code>git bisect</code>.<br />
<br />
In that case, please note the correct verb to build LuxCoreRender at each step is<br />
<pre>make clear && make deps && make</pre><br />
<br />
Caveat: this method only works for version >= v2.10.0<br />
<br />
Example for Linux (please adapt to other contexts):<br />
<br />
<pre><br />
# Start git bisecting<br />
git bisect start<br />
<br />
# Define bounds<br />
git bisect good samples-v2.10.0 # For instance<br />
git bisect bad HEAD<br />
<br />
# Build the app, test it and report status to git bisect<br />
make clear && make deps && make # Build at this stage<br />
./out/install/Release/bin/luxcoreui mytestscene/render.cfg<br />
git bisect <good|bad|skip> # Depending on above test...<br />
<br />
# Bisection loop<br />
...<br />
<br />
# At a certain point, the bisection stops and points at the faulty commit<br />
# You can reset bisection<br />
git bisect reset<br />
</pre><br />
<br />
== Can I generate debug information for dependencies (LuxCoreDeps)? ==<br />
Yes, it's possible, but only for local dependency build, for the moment.<br />
<br />
In this context, the build type is controlled by <code>DEPS_BUILD_TYPE</code> environment variable, so set it to your target build type before building:<br />
<br />
<pre>export DEPS_BUILD_TYPE=Debug</pre></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Wiki&diff=2675LuxCoreRender Wiki2026-04-24T04:02:53Z<p>Howetuft: /* LuxCore and BlendLuxCore Documentation */</p>
<hr />
<div>__NOTOC__<br />
== Users ==<br />
<br />
=== Documentation ===<br />
* [[ BlendLuxCore_Installation | BlendLuxCore Installation]]<br />
* [[ BlendLuxCore_FAQ | BlendLuxCore FAQ]]<br />
* [[ LuxCoreRender_Tutorials | Tutorials ]]<br />
* [[ LuxCoreRender_User%27s_Manual | LuxCoreRender User's Manual]]<br />
* [[ :Category:BlendLuxCore | Blender Addon User's Manual ]]<br />
* [[ PyLuxCoreTools | Command Line Tools ]]<br />
* [[ LuxMark | LuxMark Benchmark]]<br />
<br />
=== Useful links ===<br />
<br />
* [https://luxcorerender.org/ ''LuxCoreRender Home Page'']<br />
* [https://forums.luxcorerender.org/ ''LuxCoreRender Forums'']<br />
* [[ External_Resources | External Resources ]]<br />
* [[ Previous_Version | Previous Version (LuxRender) ]]<br />
<br />
== Developers & Admins ==<br />
<br />
=== LuxCore and BlendLuxCore Documentation ===<br />
<br />
==== Building & Debugging ====<br />
* [[ Building_LuxCoreRender | Building LuxCoreRender ]]<br />
* [[ Developing and debugging BlendLuxCore ]]<br />
* [[ Building LuxCoreRender - FAQ | FAQ - Building & Debugging ]]<br />
* [[ C++ Coding Guidelines ]]<br />
<br />
==== Releasing & Deploying ====<br />
* [[ Deploying LuxCoreRender | Releasing and Deploying LuxCoreRender ]]<br />
* [[ LuxCoreRender_Release_Notes | LuxCoreRender Release Notes ]]<br />
<br />
==== Maintaining ====<br />
* [[ Regular Maintenance Tasks ]]<br />
<br />
==== Interfacing ====<br />
* [[ LuxCore_API | LuxCore API ]]<br />
* [[ LuxCore_API_Reference_Manual | LuxCore API Reference Manual]]<br />
* [[ LuxCore_SDL_Reference_Manual | LuxCore SDL Reference Manual ]]<br />
<br />
==== Legacy ====<br />
* [[ Compiling_LuxCore | Building LuxCoreRender (legacy) ]]<br />
<br />
=== MaxToLux Documentation ===<br />
<br />
* [[ MaxToLux_Plugin_Release_Notes | MaxToLux Plugin Release Notes]]<br />
* [[ MaxToLux_Plugin_Reference_Manual | MaxToLux Plugin Reference Manual]]<br />
<br />
=== Tutorials ===<br />
<br />
<br />
<br />
* [[ Writing_an_Imagepipeline_Plugin | How to Write an Imagepipeline Plugin ]]<br />
* [[ Implementing_a_Texture | How to Implement a Texture ]]<br />
<br />
=== Information for Wiki Editors ===<br />
<br />
We had to close the wiki registration because of too many spambots.<br><br />
If you want to contribute to the wiki, please request an account in our [https://forums.luxcorerender.org/viewforum.php?f=10 general discussion forum].<br />
<br />
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Wiki&diff=2673LuxCoreRender Wiki2026-04-22T19:04:24Z<p>Howetuft: /* Documentation */</p>
<hr />
<div>__NOTOC__<br />
== Users ==<br />
<br />
=== Documentation ===<br />
* [[ BlendLuxCore_Installation | BlendLuxCore Installation]]<br />
* [[ BlendLuxCore_FAQ | BlendLuxCore FAQ]]<br />
* [[ LuxCoreRender_Tutorials | Tutorials ]]<br />
* [[ LuxCoreRender_User%27s_Manual | LuxCoreRender User's Manual]]<br />
* [[ :Category:BlendLuxCore | Blender Addon User's Manual ]]<br />
* [[ PyLuxCoreTools | Command Line Tools ]]<br />
* [[ LuxMark | LuxMark Benchmark]]<br />
<br />
=== Useful links ===<br />
<br />
* [https://luxcorerender.org/ ''LuxCoreRender Home Page'']<br />
* [https://forums.luxcorerender.org/ ''LuxCoreRender Forums'']<br />
* [[ External_Resources | External Resources ]]<br />
* [[ Previous_Version | Previous Version (LuxRender) ]]<br />
<br />
== Developers & Admins ==<br />
<br />
=== LuxCore and BlendLuxCore Documentation ===<br />
<br />
==== Building & Debugging ====<br />
* [[ Building_LuxCoreRender | Building LuxCoreRender ]]<br />
* [[ Developing and debugging BlendLuxCore ]]<br />
* [[ Building LuxCoreRender - FAQ | FAQ - Building & Debugging ]]<br />
* [[ C++ Coding Guidelines ]]<br />
<br />
==== Deploying ====<br />
* [[ Deploying LuxCoreRender | Releasing and Deploying LuxCoreRender ]]<br />
* [[ LuxCoreRender_Release_Notes | LuxCoreRender Release Notes ]]<br />
<br />
==== Maintaining ====<br />
* [[ Regular Maintenance Tasks ]]<br />
<br />
==== Interfacing ====<br />
* [[ LuxCore_API | LuxCore API ]]<br />
* [[ LuxCore_API_Reference_Manual | LuxCore API Reference Manual]]<br />
* [[ LuxCore_SDL_Reference_Manual | LuxCore SDL Reference Manual ]]<br />
<br />
==== Legacy ====<br />
* [[ Compiling_LuxCore | Building LuxCoreRender (legacy) ]]<br />
<br />
=== MaxToLux Documentation ===<br />
<br />
* [[ MaxToLux_Plugin_Release_Notes | MaxToLux Plugin Release Notes]]<br />
* [[ MaxToLux_Plugin_Reference_Manual | MaxToLux Plugin Reference Manual]]<br />
<br />
=== Tutorials ===<br />
<br />
<br />
<br />
* [[ Writing_an_Imagepipeline_Plugin | How to Write an Imagepipeline Plugin ]]<br />
* [[ Implementing_a_Texture | How to Implement a Texture ]]<br />
<br />
=== Information for Wiki Editors ===<br />
<br />
We had to close the wiki registration because of too many spambots.<br><br />
If you want to contribute to the wiki, please request an account in our [https://forums.luxcorerender.org/viewforum.php?f=10 general discussion forum].<br />
<br />
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Wiki&diff=2672LuxCoreRender Wiki2026-04-22T19:03:55Z<p>Howetuft: /* Documentation */</p>
<hr />
<div>__NOTOC__<br />
== Users ==<br />
<br />
=== Documentation ===<br />
* [[ BlendLuxCore_Installation | BlendLuxCore Installation]]<br />
* [[ BlendLuxCore_FAQ | BlendLuxCore FAQ]]<br />
* [[ LuxCoreRender_Tutorials | Tutorials ]]<br />
* [[ LuxCoreRender_User%27s_Manual | LuxCoreRender User's Manual]]<br />
* [[ :Category:BlendLuxCore | Blender Addon User's Manual ]]<br />
* [[ PyLuxCoreTools | Command Line Tools ]]<br />
* [[ LuxMark | LuxMark Benchmark]]<br />
<br />
=== Useful links ===<br />
<br />
* [https://luxcorerender.org/ ''LuxCoreRender Home Page'']<br />
* [https://forums.luxcorerender.org/ ''LuxCoreRender Forums'']<br />
* [[ External_Resources | External Resources ]]<br />
* [[ Previous_Version | Previous Version (LuxRender) ]]<br />
<br />
== Developers & Admins ==<br />
<br />
=== Documentation ===<br />
<br />
==== Building & Debugging ====<br />
* [[ Building_LuxCoreRender | Building LuxCoreRender ]]<br />
* [[ Developing and debugging BlendLuxCore ]]<br />
* [[ Building LuxCoreRender - FAQ | FAQ - Building & Debugging ]]<br />
* [[ C++ Coding Guidelines ]]<br />
<br />
==== Deploying ====<br />
* [[ Deploying LuxCoreRender | Releasing and Deploying LuxCoreRender ]]<br />
* [[ LuxCoreRender_Release_Notes | LuxCoreRender Release Notes ]]<br />
<br />
==== Maintaining ====<br />
* [[ Regular Maintenance Tasks ]]<br />
<br />
==== Interfacing ====<br />
* [[ LuxCore_API | LuxCore API ]]<br />
* [[ LuxCore_API_Reference_Manual | LuxCore API Reference Manual]]<br />
* [[ LuxCore_SDL_Reference_Manual | LuxCore SDL Reference Manual ]]<br />
<br />
==== Legacy ====<br />
* [[ Compiling_LuxCore | Building LuxCoreRender (legacy) ]]<br />
<br />
=== MaxToLux Documentation ===<br />
<br />
* [[ MaxToLux_Plugin_Release_Notes | MaxToLux Plugin Release Notes]]<br />
* [[ MaxToLux_Plugin_Reference_Manual | MaxToLux Plugin Reference Manual]]<br />
<br />
=== Tutorials ===<br />
<br />
<br />
<br />
* [[ Writing_an_Imagepipeline_Plugin | How to Write an Imagepipeline Plugin ]]<br />
* [[ Implementing_a_Texture | How to Implement a Texture ]]<br />
<br />
=== Information for Wiki Editors ===<br />
<br />
We had to close the wiki registration because of too many spambots.<br><br />
If you want to contribute to the wiki, please request an account in our [https://forums.luxcorerender.org/viewforum.php?f=10 general discussion forum].<br />
<br />
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Wiki&diff=2671LuxCoreRender Wiki2026-04-22T19:03:27Z<p>Howetuft: /* Documentation */</p>
<hr />
<div>__NOTOC__<br />
== Users ==<br />
<br />
=== Documentation ===<br />
* [[ BlendLuxCore_Installation | BlendLuxCore Installation]]<br />
* [[ BlendLuxCore_FAQ | BlendLuxCore FAQ]]<br />
* [[ LuxCoreRender_Tutorials | Tutorials ]]<br />
* [[ LuxCoreRender_User%27s_Manual | LuxCoreRender User's Manual]]<br />
* [[ :Category:BlendLuxCore | Blender Addon User's Manual ]]<br />
* [[ PyLuxCoreTools | Command Line Tools ]]<br />
* [[ LuxMark | LuxMark Benchmark]]<br />
<br />
=== Useful links ===<br />
<br />
* [https://luxcorerender.org/ ''LuxCoreRender Home Page'']<br />
* [https://forums.luxcorerender.org/ ''LuxCoreRender Forums'']<br />
* [[ External_Resources | External Resources ]]<br />
* [[ Previous_Version | Previous Version (LuxRender) ]]<br />
<br />
== Developers & Admins ==<br />
<br />
=== Documentation ===<br />
<br />
==== Building & Debugging ====<br />
* [[ Building_LuxCoreRender | Building LuxCoreRender ]]<br />
* [[ Developing and debugging BlendLuxCore ]]<br />
* [[ Building LuxCoreRender - FAQ | FAQ - Building & Debugging ]]<br />
* [[ C++ Coding Guidelines ]]<br />
<br />
==== Deploying ====<br />
* [[ Deploying LuxCoreRender | Releasing and Deploying LuxCoreRender ]]<br />
* [[ LuxCoreRender_Release_Notes | LuxCoreRender Release Notes ]]<br />
<br />
==== Maintaining ====<br />
* [[ Regular Maintenance Tasks ]]<br />
<br />
==== Interfacing ====<br />
* [[ LuxCore_API | LuxCore API ]]<br />
* [[ LuxCore_API_Reference_Manual | LuxCore API Reference Manual]]<br />
* [[ LuxCore_SDL_Reference_Manual | LuxCore SDL Reference Manual ]]<br />
<br />
<br />
==== Legacy ====<br />
* [[ Compiling_LuxCore | Building LuxCoreRender (legacy) ]]<br />
<br />
=== MaxToLux Documentation ===<br />
<br />
* [[ MaxToLux_Plugin_Release_Notes | MaxToLux Plugin Release Notes]]<br />
* [[ MaxToLux_Plugin_Reference_Manual | MaxToLux Plugin Reference Manual]]<br />
<br />
=== Tutorials ===<br />
<br />
<br />
<br />
* [[ Writing_an_Imagepipeline_Plugin | How to Write an Imagepipeline Plugin ]]<br />
* [[ Implementing_a_Texture | How to Implement a Texture ]]<br />
<br />
=== Information for Wiki Editors ===<br />
<br />
We had to close the wiki registration because of too many spambots.<br><br />
If you want to contribute to the wiki, please request an account in our [https://forums.luxcorerender.org/viewforum.php?f=10 general discussion forum].<br />
<br />
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Wiki&diff=2670LuxCoreRender Wiki2026-04-22T18:59:21Z<p>Howetuft: /* LuxCore */</p>
<hr />
<div>__NOTOC__<br />
== Users ==<br />
<br />
=== Documentation ===<br />
* [[ BlendLuxCore_Installation | BlendLuxCore Installation]]<br />
* [[ BlendLuxCore_FAQ | BlendLuxCore FAQ]]<br />
* [[ LuxCoreRender_Tutorials | Tutorials ]]<br />
* [[ LuxCoreRender_User%27s_Manual | LuxCoreRender User's Manual]]<br />
* [[ :Category:BlendLuxCore | Blender Addon User's Manual ]]<br />
* [[ PyLuxCoreTools | Command Line Tools ]]<br />
* [[ LuxMark | LuxMark Benchmark]]<br />
<br />
=== Useful links ===<br />
<br />
* [https://luxcorerender.org/ ''LuxCoreRender Home Page'']<br />
* [https://forums.luxcorerender.org/ ''LuxCoreRender Forums'']<br />
* [[ External_Resources | External Resources ]]<br />
* [[ Previous_Version | Previous Version (LuxRender) ]]<br />
<br />
== Developers & Admins ==<br />
<br />
=== Documentation ===<br />
<br />
==== pyLuxCore ====<br />
* [[ Building_LuxCoreRender | Building pyLuxCore ]]<br />
<br />
* [[ C++ Coding Guidelines ]]<br />
* [[ Regular Maintenance Tasks ]]<br />
<br />
==== BlendLuxCore ====<br />
* [[ Developing and debugging BlendLuxCore ]]<br />
<br />
==== Common ====<br />
* [[ Deploying LuxCoreRender | Releasing and Deploying LuxCoreRender ]]<br />
* [[ LuxCoreRender_Release_Notes | LuxCoreRender Release Notes ]]<br />
* [[ Building LuxCoreRender - FAQ | FAQ - Building & Debugging ]]<br />
* [[ LuxCore_API | LuxCore API ]]<br />
* [[ LuxCore_API_Reference_Manual | LuxCore API Reference Manual]]<br />
* [[ LuxCore_SDL_Reference_Manual | LuxCore SDL Reference Manual ]]<br />
* [[ Compiling_LuxCore | Building LuxCoreRender (legacy) ]]<br />
<br />
=== MaxToLux Documentation ===<br />
<br />
* [[ MaxToLux_Plugin_Release_Notes | MaxToLux Plugin Release Notes]]<br />
* [[ MaxToLux_Plugin_Reference_Manual | MaxToLux Plugin Reference Manual]]<br />
<br />
=== Tutorials ===<br />
<br />
<br />
<br />
* [[ Writing_an_Imagepipeline_Plugin | How to Write an Imagepipeline Plugin ]]<br />
* [[ Implementing_a_Texture | How to Implement a Texture ]]<br />
<br />
=== Information for Wiki Editors ===<br />
<br />
We had to close the wiki registration because of too many spambots.<br><br />
If you want to contribute to the wiki, please request an account in our [https://forums.luxcorerender.org/viewforum.php?f=10 general discussion forum].<br />
<br />
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Wiki&diff=2669LuxCoreRender Wiki2026-04-22T18:59:02Z<p>Howetuft: /* Documentation */</p>
<hr />
<div>__NOTOC__<br />
== Users ==<br />
<br />
=== Documentation ===<br />
* [[ BlendLuxCore_Installation | BlendLuxCore Installation]]<br />
* [[ BlendLuxCore_FAQ | BlendLuxCore FAQ]]<br />
* [[ LuxCoreRender_Tutorials | Tutorials ]]<br />
* [[ LuxCoreRender_User%27s_Manual | LuxCoreRender User's Manual]]<br />
* [[ :Category:BlendLuxCore | Blender Addon User's Manual ]]<br />
* [[ PyLuxCoreTools | Command Line Tools ]]<br />
* [[ LuxMark | LuxMark Benchmark]]<br />
<br />
=== Useful links ===<br />
<br />
* [https://luxcorerender.org/ ''LuxCoreRender Home Page'']<br />
* [https://forums.luxcorerender.org/ ''LuxCoreRender Forums'']<br />
* [[ External_Resources | External Resources ]]<br />
* [[ Previous_Version | Previous Version (LuxRender) ]]<br />
<br />
== Developers & Admins ==<br />
<br />
=== Documentation ===<br />
<br />
==== LuxCore ====<br />
* [[ Building_LuxCoreRender | Building LuxCore ]]<br />
<br />
* [[ C++ Coding Guidelines ]]<br />
* [[ Regular Maintenance Tasks ]]<br />
<br />
==== BlendLuxCore ====<br />
* [[ Developing and debugging BlendLuxCore ]]<br />
<br />
==== Common ====<br />
* [[ Deploying LuxCoreRender | Releasing and Deploying LuxCoreRender ]]<br />
* [[ LuxCoreRender_Release_Notes | LuxCoreRender Release Notes ]]<br />
* [[ Building LuxCoreRender - FAQ | FAQ - Building & Debugging ]]<br />
* [[ LuxCore_API | LuxCore API ]]<br />
* [[ LuxCore_API_Reference_Manual | LuxCore API Reference Manual]]<br />
* [[ LuxCore_SDL_Reference_Manual | LuxCore SDL Reference Manual ]]<br />
* [[ Compiling_LuxCore | Building LuxCoreRender (legacy) ]]<br />
<br />
=== MaxToLux Documentation ===<br />
<br />
* [[ MaxToLux_Plugin_Release_Notes | MaxToLux Plugin Release Notes]]<br />
* [[ MaxToLux_Plugin_Reference_Manual | MaxToLux Plugin Reference Manual]]<br />
<br />
=== Tutorials ===<br />
<br />
<br />
<br />
* [[ Writing_an_Imagepipeline_Plugin | How to Write an Imagepipeline Plugin ]]<br />
* [[ Implementing_a_Texture | How to Implement a Texture ]]<br />
<br />
=== Information for Wiki Editors ===<br />
<br />
We had to close the wiki registration because of too many spambots.<br><br />
If you want to contribute to the wiki, please request an account in our [https://forums.luxcorerender.org/viewforum.php?f=10 general discussion forum].<br />
<br />
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Wiki&diff=2668LuxCoreRender Wiki2026-04-22T18:57:29Z<p>Howetuft: /* Documentation */</p>
<hr />
<div>__NOTOC__<br />
== Users ==<br />
<br />
=== Documentation ===<br />
* [[ BlendLuxCore_Installation | BlendLuxCore Installation]]<br />
* [[ BlendLuxCore_FAQ | BlendLuxCore FAQ]]<br />
* [[ LuxCoreRender_Tutorials | Tutorials ]]<br />
* [[ LuxCoreRender_User%27s_Manual | LuxCoreRender User's Manual]]<br />
* [[ :Category:BlendLuxCore | Blender Addon User's Manual ]]<br />
* [[ PyLuxCoreTools | Command Line Tools ]]<br />
* [[ LuxMark | LuxMark Benchmark]]<br />
<br />
=== Useful links ===<br />
<br />
* [https://luxcorerender.org/ ''LuxCoreRender Home Page'']<br />
* [https://forums.luxcorerender.org/ ''LuxCoreRender Forums'']<br />
* [[ External_Resources | External Resources ]]<br />
* [[ Previous_Version | Previous Version (LuxRender) ]]<br />
<br />
== Developers & Admins ==<br />
<br />
=== Documentation ===<br />
<br />
==== LuxCore ====<br />
* [[ Building_LuxCoreRender | Building LuxCoreRender ]]<br />
* [[ Deploying LuxCoreRender | Releasing and Deploying LuxCoreRender ]]<br />
* [[ C++ Coding Guidelines ]]<br />
* [[ Regular Maintenance Tasks ]]<br />
<br />
==== BlendLuxCore ====<br />
* [[ Developing and debugging BlendLuxCore ]]<br />
<br />
==== Common ====<br />
* [[ LuxCoreRender_Release_Notes | LuxCoreRender Release Notes ]]<br />
* [[ Building LuxCoreRender - FAQ | FAQ - Building & Debugging ]]<br />
* [[ LuxCore_API | LuxCore API ]]<br />
* [[ LuxCore_API_Reference_Manual | LuxCore API Reference Manual]]<br />
* [[ LuxCore_SDL_Reference_Manual | LuxCore SDL Reference Manual ]]<br />
* [[ Compiling_LuxCore | Building LuxCoreRender (legacy) ]]<br />
<br />
=== MaxToLux Documentation ===<br />
<br />
* [[ MaxToLux_Plugin_Release_Notes | MaxToLux Plugin Release Notes]]<br />
* [[ MaxToLux_Plugin_Reference_Manual | MaxToLux Plugin Reference Manual]]<br />
<br />
=== Tutorials ===<br />
<br />
<br />
<br />
* [[ Writing_an_Imagepipeline_Plugin | How to Write an Imagepipeline Plugin ]]<br />
* [[ Implementing_a_Texture | How to Implement a Texture ]]<br />
<br />
=== Information for Wiki Editors ===<br />
<br />
We had to close the wiki registration because of too many spambots.<br><br />
If you want to contribute to the wiki, please request an account in our [https://forums.luxcorerender.org/viewforum.php?f=10 general discussion forum].<br />
<br />
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Wiki&diff=2667LuxCoreRender Wiki2026-04-22T18:55:50Z<p>Howetuft: /* Documentation */</p>
<hr />
<div>__NOTOC__<br />
== Users ==<br />
<br />
=== Documentation ===<br />
* [[ BlendLuxCore_Installation | BlendLuxCore Installation]]<br />
* [[ BlendLuxCore_FAQ | BlendLuxCore FAQ]]<br />
* [[ LuxCoreRender_Tutorials | Tutorials ]]<br />
* [[ LuxCoreRender_User%27s_Manual | LuxCoreRender User's Manual]]<br />
* [[ :Category:BlendLuxCore | Blender Addon User's Manual ]]<br />
* [[ PyLuxCoreTools | Command Line Tools ]]<br />
* [[ LuxMark | LuxMark Benchmark]]<br />
<br />
=== Useful links ===<br />
<br />
* [https://luxcorerender.org/ ''LuxCoreRender Home Page'']<br />
* [https://forums.luxcorerender.org/ ''LuxCoreRender Forums'']<br />
* [[ External_Resources | External Resources ]]<br />
* [[ Previous_Version | Previous Version (LuxRender) ]]<br />
<br />
== Developers & Admins ==<br />
<br />
=== Documentation ===<br />
<br />
==== LuxCore ====<br />
* [[ Building_LuxCoreRender | Building LuxCoreRender ]]<br />
* [[ Deploying LuxCoreRender | Releasing and Deploying LuxCoreRender ]]<br />
* [[ Building LuxCoreRender - FAQ | FAQ - Building & Debugging LuxCoreRender ]]<br />
* [[ C++ Coding Guidelines ]]<br />
* [[ Regular Maintenance Tasks ]]<br />
<br />
==== BlendLuxCore ====<br />
* [[ Developing and debugging BlendLuxCore ]]<br />
<br />
==== Common ====<br />
* [[ LuxCoreRender_Release_Notes | LuxCoreRender Release Notes ]]<br />
* [[ LuxCore_API | LuxCore API ]]<br />
* [[ LuxCore_API_Reference_Manual | LuxCore API Reference Manual]]<br />
* [[ LuxCore_SDL_Reference_Manual | LuxCore SDL Reference Manual ]]<br />
* [[ Compiling_LuxCore | Building LuxCoreRender (legacy) ]]<br />
<br />
=== MaxToLux Documentation ===<br />
<br />
* [[ MaxToLux_Plugin_Release_Notes | MaxToLux Plugin Release Notes]]<br />
* [[ MaxToLux_Plugin_Reference_Manual | MaxToLux Plugin Reference Manual]]<br />
<br />
=== Tutorials ===<br />
<br />
<br />
<br />
* [[ Writing_an_Imagepipeline_Plugin | How to Write an Imagepipeline Plugin ]]<br />
* [[ Implementing_a_Texture | How to Implement a Texture ]]<br />
<br />
=== Information for Wiki Editors ===<br />
<br />
We had to close the wiki registration because of too many spambots.<br><br />
If you want to contribute to the wiki, please request an account in our [https://forums.luxcorerender.org/viewforum.php?f=10 general discussion forum].<br />
<br />
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Wiki&diff=2666LuxCoreRender Wiki2026-04-22T18:54:30Z<p>Howetuft: /* Documentation */</p>
<hr />
<div>__NOTOC__<br />
== Users ==<br />
<br />
=== Documentation ===<br />
* [[ BlendLuxCore_Installation | BlendLuxCore Installation]]<br />
* [[ BlendLuxCore_FAQ | BlendLuxCore FAQ]]<br />
* [[ LuxCoreRender_Tutorials | Tutorials ]]<br />
* [[ LuxCoreRender_User%27s_Manual | LuxCoreRender User's Manual]]<br />
* [[ :Category:BlendLuxCore | Blender Addon User's Manual ]]<br />
* [[ PyLuxCoreTools | Command Line Tools ]]<br />
* [[ LuxMark | LuxMark Benchmark]]<br />
<br />
=== Useful links ===<br />
<br />
* [https://luxcorerender.org/ ''LuxCoreRender Home Page'']<br />
* [https://forums.luxcorerender.org/ ''LuxCoreRender Forums'']<br />
* [[ External_Resources | External Resources ]]<br />
* [[ Previous_Version | Previous Version (LuxRender) ]]<br />
<br />
== Developers & Admins ==<br />
<br />
=== Documentation ===<br />
<br />
==== LuxCore ====<br />
* [[ Building_LuxCoreRender | Building LuxCoreRender ]]<br />
* [[ Deploying LuxCoreRender | Releasing and Deploying LuxCoreRender ]]<br />
* [[ Building LuxCoreRender - FAQ | FAQ - Building & Debugging LuxCoreRender ]]<br />
* [[ C++ Coding Guidelines ]]<br />
* [[ Regular Maintenance Tasks ]]<br />
<br />
==== BlendLuxCore ====<br />
* [[ Developing and debugging BlendLuxCore ]]<br />
* [[ Compiling_LuxCore | Building LuxCoreRender (legacy) ]]<br />
* [[ LuxCoreRender_Release_Notes | LuxCoreRender Release Notes ]]<br />
* [[ LuxCore_API | LuxCore API ]]<br />
* [[ LuxCore_API_Reference_Manual | LuxCore API Reference Manual]]<br />
* [[ LuxCore_SDL_Reference_Manual | LuxCore SDL Reference Manual ]]<br />
<br />
=== MaxToLux Documentation ===<br />
<br />
* [[ MaxToLux_Plugin_Release_Notes | MaxToLux Plugin Release Notes]]<br />
* [[ MaxToLux_Plugin_Reference_Manual | MaxToLux Plugin Reference Manual]]<br />
<br />
=== Tutorials ===<br />
<br />
<br />
<br />
* [[ Writing_an_Imagepipeline_Plugin | How to Write an Imagepipeline Plugin ]]<br />
* [[ Implementing_a_Texture | How to Implement a Texture ]]<br />
<br />
=== Information for Wiki Editors ===<br />
<br />
We had to close the wiki registration because of too many spambots.<br><br />
If you want to contribute to the wiki, please request an account in our [https://forums.luxcorerender.org/viewforum.php?f=10 general discussion forum].<br />
<br />
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2665Deploying LuxCoreRender2026-04-20T05:13:15Z<p>Howetuft: /* Samples Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2664Deploying LuxCoreRender2026-04-20T05:12:10Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2663Deploying LuxCoreRender2026-04-20T05:11:26Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2662Deploying LuxCoreRender2026-04-20T05:11:05Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2661Deploying LuxCoreRender2026-04-20T05:10:38Z<p>Howetuft: /* Pre-Flight Review */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for wheels.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2660Deploying LuxCoreRender2026-04-20T05:09:12Z<p>Howetuft: /* Sufficient space on PyPI and PyPI-test */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, nor used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for wheels.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2659Deploying LuxCoreRender2026-04-19T18:48:18Z<p>Howetuft: /* BlendLuxCore Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, nor used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for wheels.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2658Deploying LuxCoreRender2026-04-19T18:47:53Z<p>Howetuft: /* BlendLuxCore Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, nor used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for wheels.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2657Deploying LuxCoreRender2026-04-19T18:46:49Z<p>Howetuft: /* Samples Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, nor used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for wheels.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2656Deploying LuxCoreRender2026-04-19T18:45:43Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, nor used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for wheels.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts and thus to clear 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2655Deploying LuxCoreRender2026-04-19T18:44:50Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, nor used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for wheels.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
(this is a test step, before uploadig to real PyPI) <br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts and thus to clear 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2654Deploying LuxCoreRender2026-04-19T18:44:35Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, nor used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for wheels.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them, through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
(this is a test step, before uploadig to real PyPI) <br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts and thus to clear 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2653Deploying LuxCoreRender2026-04-19T18:43:38Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
<br />
== Clean Branches ==<br />
<br />
The procedure assumes the releases can be created from the <i>default branches</i> in each repository, namely (2026-04-19):<br />
* <code>master</code> for LuxCore<br />
* <code>main</code> for BlendLuxCore<br />
Please check the above branches contain all the history you target for your releases and, if not, please make the required git plumbing.<br />
<br />
== LuxCore Buildability ==<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, nor used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for wheels.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
(this is a test step, before uploadig to real PyPI) <br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>Unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts and thus to clear 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
Rebuild all: <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Announcements ==<br />
<To be completed by @codehd></div>Howetuft