Build system simplification and rework

[stijnvanbeek]

Build system simplification and rework

Introduction

While at the start of this year I was in the process of adding support for Apple Silicon architectures and codesigning on Mac OS I ran into a few complications with the NAP build system:

• Because of the combined use of python and cmake, and different scripts in different languages calling one another it was hard to debug and trace what exactly was going on.
• Because of the need to build a framework package first in order to be able to build a packaged app the iteration time to test changes in the core build system and how they turn out in a packaged app was very long.
• Adding new modules to the system (especially with new third party dependencies) required quite some boilerplate code with some code duplication for each module or dependency.

Finally I set out to write a new NAP build system with the following objectives:

• Being able to build packaged, distributable apps from a freshly cloned NAP repository using a single command from the command line.
• Simplify the process of adding new modules or apps to the NAP source
• Simplify the task of adding thirdparty dependencies to a NAP module.
• Refer to platforms or architectures as little as possible in the code, and try to find one-fits-all solutions. This way support for new platforms or architectures is more easily added to the system.
• Write everything in one single language: cmake

This draft PR presents the first working result.

How it works

From a freshly cloned repository on this branch, you can build distributable apps. Type:

>sh package_app.sh helloworld

This results in a packaged helloworld app in the install subdirectory of your nap source. Note: on windows you need a powershell for this to be able to run sh scripts, but the script works on linux, windows and Mac OS.

If you want to build multiple apps in a row, and you don't want all the NAP modules to be rebuilt for each app, you can also specify a build directory that will be created, left intact after build, and reused:

>sh package_app.sh helloworld build_directory
>sh package_app.sh audioplayback build_directory

Note: on linux and mac OS the script will instruct you to install the jq utility to be able to read the app title from app.json.

The script doesn't do all much more than just calling cmake for configuration, build and installation:

cmake -S . -B build_directory -DCMAKE_BUILD_TYPE=Release -DAPP_INSTALL_NAME=HelloWorld
cmake --build build_directory --target helloworld
cmake --install build_directory --prefix install

If you want to create a solution or project file for the NAP repository for your IDE you can add the corresponding cmake generator in the configuration:

`cmake -S . -B build_directory -G"Visual Studio 16 2019"

Adding modules or apps

The modules and apps directories in the NAP source are scanned for modules and apps by the cmake configuration script. All modules and apps with a module.json and app.json file are added as targets to the system automatically. This also applies to demos that come with apps and modules that belong to an app.
The system will generate default CMakeLists.txt files if they are not not present:

For modules:
include(${NAP_ROOT}/cmake/nap_module.cmake)
For apps:
include(${NAP_ROOT}/cmake/nap_app.cmake)

The module_extra.cmake files are still supported for backwards compatibility. However it is also possible (and possibly more clean) to just add additional cmake code for your module to the corresponding CMakeLists.txt file.

Following steps

1. Napkin

It is possible to build and run Napkin as a target from within the build directory or IDE and to use it to open project json files and edit the app structure. It is also possible to build and run Napkin as a packaged app just like any other app target. However in this form Napkin tries to open the module descriptors in its own package instead of the one belonging to the app that is being opened for editing. I think this could be relatively easy to fix, but I would love your input on this @cklosters.

2. Testing and verification

Scripts and tools need to be written to verify all targets build successfully and can be linked correctly into packaged apps. Opening packaged apps in Napkin will also be part of this. These scripts need to be hooked up to the build system in order to be able to verify everything works correctly on all platforms.

3. Porting all system modules and demos

Not all system modules and demos have been ported to the new build system yet. In order to complete this hooking the system up to the build system is a necessity.

[cklosters]

Thanks for this PR @stijnvanbeek, looping in @TimGroeneboom - I think it's important we get his view as a developer building and deploying large NAP applications in production as well.

[TimGroeneboom]

Hey, I will definitely take a look and view it trough the lens of our use-cases, will take some time for this next week,

[cklosters]

We revamped the build system with the release of NAP 0.6 and, for now, do not plan to make significant changes unless required or prioritized. However, we do believe it holds significant potential for integration in a future version of NAP.

Unfortunately, I don’t have the time to review this at the moment. It’s a significant change that impacts & breaks existing functionality, integrating it would require considerable time and attention, which I’m currently unable to allocate. I can however list it as an experimental branch in the readme, so others are encouraged to try it out and potentially comment on it.