cmake: improve godbolt-minimal preset for Compiler Explorer

[GitMasterJatin]

The existing godbolt-minimal preset (added in #7063) is missing several flags required for a correct Compiler Explorer integration:

1. Add HPX_WITH_DISTRIBUTED_RUNTIME=OFF: HPX_WITH_NETWORKING=OFF alone does not disable the distributed runtime -- AGAS, actions, and the parcelset infrastructure are still compiled, wasting ~30% build time and producing libraries that CE will never use.

2. Add HPX_WITH_CXX_STANDARD=20: pins the C++ standard explicitly so builds are deterministic across GCC/Clang versions. Uses HPX's own cache variable (not CMAKE_CXX_STANDARD, which HPX rejects unless HPX_USE_CMAKE_CXX_STANDARD is also set).

3. Add HPX_WITH_TOOLS=OFF: CE only needs libraries and headers; building HPX tools adds unnecessary build time.

4. Improve description: document the produced static libraries (libhpx_wrap.a, libhpx_init.a, libhpx.a, libhpx_core.a) and the required -Wl,-wrap=main linker flag for non-CMake consumers.

5. Reorder cache variables to group related flags logically: standard -> linking -> runtime -> dependencies -> build targets.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[StellarBot]

Can one of the admins verify this patch?

[hkaiser]

Well, I believe we specifically left HPX_WITH_DISTRIBUTED_RUNTIME=ON as this leaves components and actions available even in local scenarios. We can certainly argue what minimal functionalities we should enable on Godbolt.

[hkaiser]

Well, I believe we specifically left HPX_WITH_DISTRIBUTED_RUNTIME=ON as this leaves components and actions available even in local scenarios. We can certainly argue what minimal functionalities we should enable on Godbolt.

What's your opinion on this?

[GitMasterJatin]

Well, I believe we specifically left HPX_WITH_DISTRIBUTED_RUNTIME=ON as this leaves components and actions available even in local scenarios. We can certainly argue what minimal functionalities we should enable on Godbolt.

What's your opinion on this?

Yes @hkaiser Sir keeping HPX_WITH_DISTRIBUTED_RUNTIME = ON makes sense so CE users can still explore actions and components locally. I'll drop that change. The rest of the PR (HPX_WITH_CXX_STANDARD=20, HPX_WITH_TOOLS=OFF, updated description, and reordering) is independent of this happy to keep those if they look good to you.

[hkaiser]

Well, I believe we specifically left HPX_WITH_DISTRIBUTED_RUNTIME=ON as this leaves components and actions available even in local scenarios. We can certainly argue what minimal functionalities we should enable on Godbolt.

What's your opinion on this?

Yes @hkaiser Sir keeping HPX_WITH_DISTRIBUTED_RUNTIME = ON makes sense so CE users can still explore actions and components locally. I'll drop that change. The rest of the PR (HPX_WITH_CXX_STANDARD=20, HPX_WITH_TOOLS=OFF, updated description, and reordering) is independent of this happy to keep those if they look good to you.

HPX_WITH_CXX_STANDARD=20 is the default, so there is no need to specify that. HPX_WITH_TOOLS=OFF is a valid change.

[hkaiser]

One thing I wanted to ask all along: why do we build HPX as a set of static libraries on godbolt?

[GitMasterJatin]

@hkaiser Sir, I looked into this more carefully.

Static linking is not strictly required by Compiler Explorer. CE supports both .a and .so libraries, and it can pass -L and -Wl,-rpath for shared libraries at link/run time. So the “required” claim in #7063 was too strong.

That said, there are some practical reasons why static linking is a better fit for HPX on CE:

1. Self-contained executables

When a user clicks Execute on CE, the binary just works.
There’s no need to manage runtime paths like LD_LIBRARY_PATH or deal with missing shared libraries in the sandbox.

2. HPX initialization & linking complexity

HPX relies on:

• -Wl,-wrap=main
• Specific link order: -lhpx_wrap -lhpx_init -lhpx -lhpx_core

With static linking, all symbols are resolved at link time.
This avoids potential runtime issues (e.g., dlopen / symbol resolution) in CE’s sandboxed environment.

3. Simpler CE integration

Using static libraries means:

• CE config only needs to point to .a files
• No need to manage LD_LIBRARY_PATH
• No concerns about versioning or SONAME conflicts across different compilers

That said, shared libraries could still have advantages (e.g., faster link times, reduced storage per compiler).

If you think shared linking would be a better direction, I’m happy to switch the preset.

[hkaiser]

Let's leave the static build option, if only to have a proper test for this mode as well ;-)