Closed axel-h closed 5 months ago
I am using the same nanoPB version, but just a different directory layout. Symlinking is not really an option, as this would be the only thing that needs the project workspace and tools folder then.
I did not get things to work with just adding nanoPB to the CMAKE_MODULE_PATH
. Making this work could be another mire generic way, but it may need more changes.
The directory layout seems quite hard-coded, how do you manage the other tools paths? Is it worth trying to re-use settings.cmake? It doesn't seem to be doing that much useful work.
Providing -DCMAKE_MODULE_PATH=...
works well enough for all other modules.
Concerning your question about using settings.cmake
or not, that is where https://github.com/seL4/sel4test/pull/40 is aiming for to allow full customization. But as stated there, settings.cmake
contains some useful parts, so using it has some benefits.
Since sel4bech
basically uses the same settings.cmake
, but does not need the patch, I have been digging a bit more into this. It seems sel4test
is running in to the issues described at https://stackoverflow.com/questions/75619926/does-cmake-set-internal-apply-force because CMake runs settings.cmake
twice here (at least when targeting QEMU, the logs show this). The second runs finally makes INTERNAL
act in FORCE
-mode and overwrite the command line setting. In sel4bench
it runs only once, so the command line value is used.
I still think we should not use INTERNAL
here (and also apply this patch in sel4bench
). There is a message we print in https://github.com/seL4/seL4_tools/blob/8c660fd6d8ba60aa4c76d5c9586e3892502d8e0e/cmake-tool/helpers/nanopb.cmake#L22 that also implies this values is supposed to be be something one can set on the command line.
INTERNAL
has the same effect asFORCE
, so passing any-DNANOPB_SRC_ROOT_FOLDER=...
to CMake on the command line will be overwritten and there is no way to customize the path then.