Building LuxCoreRender

This page is under construction

This document describes the various processes involved in building LuxCoreRender, starting with version 2.10 “Back-on-track”.

LuxCoreRender's build system has been significantly modified for version 2.10. This document therefore renders obsolete all previous documents related to the compilation of older versions (<=2.9).

For most targets, there are several build approaches, depending on the use case. This document therefore distinguishes 2 different build workflows.

Audience

This document is primarily intended for:

• LuxCoreRender administrators in charge of releasing the various LuxCoreRender end-products;
• Developers wishing to contribute to the project;
• Package maintainers wishing to integrate all or part of LuxCoreRender into a distribution;

This document assumes that the reader is skilled in the following areas:

• C/C++ compilation
• cmake
• git
• Github
• Python Wheels

Familiarity with Conan dependency manager may also help.

This document is not intended for end-users without any knowledge about application building. Such users are invited to look for already compiled binaries.

Build Targets

Synoptics

LuxCoreRender contains multiple targets, below represented with dependency links:

Target	Source Repository	Content
External Dependencies	LuxCoreRender/LuxCoreDeps	A bundled Conan cache populated with LuxCoreRender external dependency binaries, built from sources. Please refer to LuxCoreDeps README for more information.
LuxCore	LuxCoreRender/LuxCore	LuxCore core binaries, in the form of static and shared libraries: luxcore.so, luxcore_static.lib, luxcore.dll etc.
Samples	LuxCoreRender/LuxCore	Sample C++ programs, illustrating luxcore use, namely luxcoreconsole and luxcoreui
Python Wheels	LuxCoreRender/LuxCore	Python bindings of core binaries, in the form of Python wheels (1 per pair Platform/Python version). As a byproduct, a Pythonized version of LuxCore shared library is also built (pyluxcore.so).
Plugins	LuxCoreRender/<plugin-repo>	Plugins to expose LuxCore in various external applications, notably Blender. Mostly written in Python and relying on Python Wheels as runtime dependency.
Python LuxCore Tools (PyLuxCoreTools)	LuxCoreRender/LuxCore	Set of command line tools based on pyluxcore, written in Python.

Targeted platforms

LuxCoreRender aims at being available on the following 4 platforms:

• Linux (glibc 2.28+)
• Windows
• MacOS Intel (>=10.15)
• MacOS Arm (>=12.0)

For Python-related targets,LuxCoreRender aims at being available for all Python versions supported at a given time (https://devguide.python.org/versions/).

Scope of this document

The scope of this document is:

• External Dependencies
• LuxCore
• Python Wheels
• Samples

Plugin builds are documented in dedicated wiki pages.
PyLuxCoreTools build documentation is in "TODO" status.

Build Workflows

Publisher Workflows

Introduction

These workflows are designed to be used by LuxCoreRender administrators to publish a new release of one or more LuxCoreRender components.

They exclusively take place in a CI/CD Github pipeline.

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 #Developper Workflows to learn how to get code ready for final build.

Running these workflows require users to be granted of extended rights on LuxCoreRender repositories.

External Dependencies

Caveat: if you provide an already-existing release version number during the process, this action will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.

To build a new release of Dependencies:

Python Wheels

Standard Build

Caveat: if you provide an already-existing release version number during the process, this action will replace the existing release with the newly-built one. This can be what you expected... or not. Be cautious.

Prerequisite: you must have release a compatible version of External Dependencies (LuxCoreDeps) before building Python Wheels.

To build a new release of Python Wheels:

Test & Debug Build

Standard build may not be suitable for testing and debugging needs (for instance, when modifying build process...). In such situations, there are 3 options:

• Server build: run workflow on server, but without creating any release
• Local build - run workflow: run workflow on local computer (user PC)
• Local build - developper:

Server build

The process is nearly the same as canonical build, but the release creation steps are skipped. For that purpose, another Github workflow is executed: LuxCore Dependency Builder.
Please note that your changes must have been committed to repository beforehand.

If build succeeds, you will find the expected outputs in Artifacts section of the action run.

Local build
Thanks to nektos/act, it is possible Github Workflows locally.

After installation (left to the reader), act can be called directly on command line. For more convenience, a script is also provided in LuxCoreDeps repository: utils/debug.sh (Linux only, at the moment).

Wheels Deployment

As far as wheels are concerned, in addition to building them, it is also necessary to upload them to PyPi ("deploy" them), so that they are available for pip installation.

Prerequisite: you must have released a set of Python Wheels beforehand.

Samples

As we plan to replace Samples by Python tools, there is no Releaser workflow, just a Builder one. Releases have to be created manually, on the basis of Builder's artifacts.

Developper Workflows

Introduction

These workflows are designed for development, debugging and test steps.

Their purpose is to prepare the code for publication. To fully understand this section, we recommend you take a look at the #Publisher Workflows beforehand.

External Dependencies

To build external dependencies in development process, there are 2 options:

• Server build: run workflow on server, but without creating any release
• Local build: run workflow on local computer (user PC)

Local build is generally faster than server build and does not require to commit changes beforehand. However, it builds only for the platform where it is executed and can be slightly altered by local conditions (build tools local versions etc.).

Therefore, the recommended workflow is:

• Fork LuxCoreDeps in Github and clone your fork locally
• Make development/debugging cycles in local environment with the help of local build
• When local build is successful, commit changes, push to your Github fork and run server build (actually, the run should be triggered by push action). Check that the build succeeds for all platforms, in server conditions. If not, fix the issues and push again, till everything is ok.
• When server build succeeds, PR to LuxCore/LuxCoreDeps

Server build

The process is nearly the same as publisher build, but the release creation steps are skipped. For that purpose, another Github workflow is executed: LuxCore Dependency Checker.
Please note that your changes must have been committed to repository beforehand.

If build succeeds, you will find the expected outputs in Artifacts section of the action run.

Local build

This build relies on nektos/act. Thanks to this very smart tool, it is possible Github Workflows locally. See install instructions on their website.

After installation, act can be executed directly on command line: call it to run workflows located in .github/workflows folder.
For more convenience, a wrapper script is also provided in LuxCoreDeps repository: utils/debug.sh (Linux only, at the moment).

LuxCore & Samples

To build LuxCore & Samples in development process, there are 3 methods:

• Local build - make wrapper
• Local build - Github workflow
• Server build: run workflow on server, but without creating any release

Caption text

Method	Description	Pros	Cons
Local build - make wrapper	Execute cmake statements via make wrapper	Very fast (incremental). Do not require to commit changes beforehand	Affected by local conditions (tool versions, libc version, system deps...). Build only for local platform
Local build - Github workflow	Execute Github workflow locally	Fast. More robust to local conditions (containerized). Do not require to commit changes beforehand	Slower than make wrapper (rebuild all every time). Can be slightly affected by local conditions
Server build	Execute Github workfow on server, without issuing a release	Build in Release environment	Slow. Requires to commit changes beforehand.

Miscellaneous

TODO Python Wheels: Pointer to deps Semantic Versioning