|
Nuke.Unreal
Build Unreal apps in Style.
|
Nuke.Unreal allows you to set up boilerplate for C++ libraries, or fetch them via a package manager. In all cases the artifacts it generates are placed in the working directory (the current location of your terminal), and they're managed in their own preparation targets which are generated for you.
There are three methods available:
XRepo is an emerging C++ package manager relying on the build tool XMake (made by the same people). Nuke.Unreal taps into that ecosystem and has tools to convert their packages into Unreal modules. Tt can be as simply used as the following:
or fully specified with version and library options:
and multiple libraries can be set up in one go
XMake/XRepo can act like a meta-package-manager (using for example vcpkg::spdlog) however that feature is not supported by Nuke.Unreal as package information is not consistently reported by XRepo for external package managers. Nuke.Unreal may have support for other package managers in the future on its own properly implemented.
Video demonstrating the installation of a C++ library.
use-xrepo will not fetch the specified libraries immediately but rather generate build plugins for them, which define Prepare-<library> targets. These are all dependent for Prepare target of UnrealBuild which is then dependent for Generate. So after nuke use-xrepo running nuke prepare or nuke generate will fetch and install properly all libraries used in this way. Having an extra build plugin allows the developer to further customize how the library is used, add extra necessary operations or change parameters after-the-fact.
--spec follows this syntax:
MD C runtime linkage ‘runtimes='MD’` is implicitly added by Nuke.Unreal.The Prepare and the individual Prepare-<library> targets will generate partial module rule classes for the platforms they were invoked for. This is done because libraries may have different requirements based on which platform they're used on / compiled on. The main MyLibrary.Build.cs module rule is the place for the developer to add custom logic if that's necessary for the library. Individual MyLibrary.Platform.Build.cs partial rules set up includes and libs.
*.nuke.cs preparation script.The main benefit of this design is that libraries prepared this way can be further distributed with source but without the need for Nuke.Unreal, or without the need to execute complex behavior from the module rule files. This ensures for example Fab compliance of plugins.
Current table of platform support for managing C++ libraries this way. Columns are host development platforms and rows are targeted platforms (cross-compile)
| Windows | Linux | Mac¹ | |
|---|---|---|---|
| Windows | ✔ | ❌ | ❌ |
| Linux | ⚠️³ | ✔ | ❌ |
| MacOS | ❌ | ❌ | ?? |
| Android | ✔ | ✔ | ?? |
| Apple² | ❌ | ❌ | ?? |
This generates build plugins allowing the developer to prepare libraries via CMake. Fetching and storing the library is the responsibility of the developer. The build plugin is prepared for the most trivial use case when compiling a library via CMake but one may need to modify that depending on the design decisions of the library being used.
CMake support currently is pretty barebones but will improve in the future (like adding automatic cross-compile toolchain setup).
This will directly generate only the module rule file without the need for extra preparations like with the xrepo or the CMake methods.