Fix FAASM_SGX flag

[csegarragonz]

In a previous PR (#590) I had to overwrite the FAASM_SGX CMake variable to set it to ON explicitly to make sure the SGX code was being built and tested. My fix was too brute, and broke the option to disable the SGX build, which is why the flag was introduced in the first place.

The crux of the problem is that, even though the default value is now ON, it is cached (in CMakeCache.txt) as OFF from when the container image was built. As a consequence, if we don't set FAASM_SGX to ON explicitely, it will be set to OFF. As a proof of concept, I print all cached variables in an action run, where we can see that FAASM_SGX is set to OFF.

One possible workaround is to re-build the container images with a different default value, so that it gets properly cached. Another workaround (the one I have chosen) is to unset the variable from the CMake cache so that it is either the default (ON) or OFF if overriden from the command line.

Relevant links:

• https://gitlab.kitware.com/cmake/cmake/-/issues/21708
• https://stackoverflow.com/questions/44719963/cmake-default-value-for-options-doesnt-work/44720601#44720601
• https://gitlab.kitware.com/cmake/cmake/-/issues/14756#note_258579

[csegarragonz]

@KubaSz Could you check what I say makes any sense at all?

[eigenraven]

Because you're already using python scripts for everything, imo the best solution is to always pass -DFAASM_SGX=value to cmake, on/off and just not relying on the default value.

The cache keeps whatever was last used and really shouldn't be overwritten by the cmake scripts, as it's intended for user configuration and cmake will rerun itself with no extra arguments to regenerate build files keeping old cache settings.

Personally I've been using CMake presets (https://cmake.org/cmake/help/v3.22/manual/cmake-presets.7.html, https://github.com/auto-ndp/faasm/blob/master/CMakePresets.json) as they're very convenient for local builds and integrate well with vscode/clion unlike the python-based configuration, you may want to look into those to have a couple of pre-set configuration sets like docker, tests, local build, etc.

[csegarragonz]

Ok thanks, I was not sure about tampering with the cache manually. To fix the current bug I think it makes more sense to just amend the CLI script.

[Shillaker]

Wow, good catch!