cmake, doc: Update build-openbsd.md

[hebasto]

No description provided.

[hebasto]

Friendly ping @theStack :)

[theStack]

Concept ACK

Following the build instructions on OpenBSD 7.5 succeeded for the "Descriptor Wallet and GUI" scenario ✔️ , will still play a bit around with different configurations (in particular, building with BerkeleyDB).

[hebasto]

@theStack @fanquake

Thank you for your reviews! Your comments have been addressed.

[fanquake]

Aren't we using modern CMake invocations, where this isn't needed?

[hebasto]

I think this is a better option for the documentation purpose:

The point is the mkdir build && cd build invocation guaranties the clean build environment. Another benefit of cd build is that there is no need to specify the --test-dir option when running ctest.

[fanquake]

Right, but isn't the point of using a dir, that you can just blow it away, and guarantee a clean env? i.e I'll regularly just rm -r build, and then re-run CMake commands, without having to hop around in directories.

[hebasto]

I do the same :)

Or use the --fresh option.

But I believe that the documentation should be foolproof. It has to suggest the safest way to do things. Users will find their own ways that suit their needs better.

[fanquake]

It has to suggest the safest way to do things.

Why is using mkdir and cd safer than using the CMake option that exists to do exactly the same thing?

[fanquake]

I think it's because -B will reuse an existing dirty build directory

Sure, but there's nothing preventing a user who's hopping around dirs and always recreating them manually from accidently doing the exact same thing?

[m3dwards]

You are right but in terms of documentation, how do we know that their build directory is empty? A mkdir sets the expectation that this directory didn't already exist.

[fanquake]

That only works the first time, and nowhere do we tell users to cleanup and recreate their build dirs, so anyone who's already built once, could easily re-use the same build dir with different code etc.

[hebasto]

Reworked.

[vasild]

mkdir ensures pristine build directory only if we assume that the user will stop if it gives an error. I can imagine some users continuing nevertheless (I have seen people that don't recognize error messages from normal diagnostic messages or just accidentally don't read that extra line on the screen which reads "mkdir: build: File exists").

If we want to stress on clean build directory then we need to start with a command like rm -fr build or cmake --fresh.

[hebasto]

The cmake and ctest invocations have been modernized (discussed during today's call).

[theStack]

Tested ACK f8994d1

I can confirm that the cmake build/test instructions work as expected on OpenBSD 7.5.

Some differences I found between autotools vs. cmake that could potentially confuse/disturb users:

• $ ./configure --help shows the available options immediately, while $ cmake -B build -LH performs some checks already before options are shown, which takes significantly longer, at least on the first run. Is there way to get the config options instantly? (other than looking into CMakeLists.txt manually, or some workaround like $ grep ^option CMakeLists.txt?)
• Calling $ ./configure with an option that errors (e.g. due to missing package/header) and then calling it again without that option works fine. With CMake, it seems that once an option is passed, it is saved, so removing the option in another call still fails. E.g.:

$ cmake -B build -DWITH_UPNPC=ON
...
CMake Error at /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find MiniUPnPc (missing: MiniUPnPc_LIBRARY MiniUPnPc_INCLUDE_DIR
  MiniUPnPc_API_VERSION_OK)
...
$ cmake -B build
< still fails with the same error... >

No strong opinion, but it seems using --fresh mitigates the second problem and could be slightly less confusing?

[hebasto]

• Calling $ ./configure with an option that errors (e.g. due to missing package/header) and then calling it again without that option works fine. With CMake, it seems that once an option is passed, it is saved, so removing the option in another call still fails.

What about passing this option in another call with OFF value?

[hebasto]

• $ ./configure --help shows the available options immediately, while $ cmake -B build -LH performs some checks already before options are shown, which takes significantly longer, at least on the first run.

Right. The approaches are quite different. CMake shows the cached variables, which means the cache is generated first.

Is there way to get the config options instantly?

No, if using cmake binary.