The recommended pattern for options is to include the name of the project, so that projects can compose. Defaulting to is top level is the right thing, but we wouldn't want to build the tests of beman_interface if we included that.
Was going to come back to fix, but if we're touching this, might as well.

better solution may be found here: https://github.com/beman-project/execution26/tree/main/.github/workflows

Can you provide more description here? What are you trying to do?

Hey CK, I would suggest you defer further improvement to another PR. Leaving a note here with some explanation on what improvements would be needed should be sufficient.

This PR is currently already complex and changes suggested to the build system are affecting fundamentals to our setup, it may be best to leave this PR in a stable state so other beman project members can perform reviews. As it may take some time for members to discuss the implications of the build updates.

Having small, atomic PRs also help all of us manage changes easily, as the longer this PR is hanging in the review queue, the more out of date this PR is in respect to other pending improvements, this applies to both sides.

Again thank you for your contribution.

Yes, at the moment, I have no plan to change more on this PR.
But there are to FIXME in my changes and I have no advice how to continue?

For me, your CI workflow tries to match.

I would split the CI in OS specific parts, reduce the compiler versions, and the C++ standards you want to check.
Also I would also create CI specific cmake workflow presets and use them.

see too CMakeWorkflowPresets: How to keep it as simple as possible?

Propagating the project settings is exactly what we want to do. It's why gtest recommends vendoring rather than packaging.

What if your build dependencies doesn't compile with your compiler flags?

Then the code is likely fundamentally incompatible? Except for warning flags, pretty much all other flags are detectable changes that will compile differently, leading to ODR violations, sometimes just harmless. This is true even for the standard library to some extent, although standard library implementors go to great lengths to avoid such breaks.
Feature test macros and polyfills are common examples. Standard library implementation choice (libc++ vs libstdc++) is another.
It's possible that some flags are peculiar to a package, or there are exceptional workarounds necessary, but by default all C++ in a link context should be compiled with the same flags.

see #66 (comment)

Any reason not to keep /opt? It's usually a path used for Linux libraries and I think that path should also exist for MAC OS.

Yes, but /opt is owned by root.
I would use ${PWD}/stagedir like boost does.

I think we supposed regardless of who is owner of /opt, all users can create a subdirectory or whatever.

My point is that /opt is used in all repos in Beman right now in documentation. If this recommendation is not OK, I'm OK to change it everywhere (other PRs for docs), but if it's works, I won't do the change.

I will also test and come back.

from CI build on MAC OS:

ld: warning: ignoring duplicate libraries: 'lib/Release/libgtest.a'
[1/1] Building CXX object src/beman/exemplar/CMakeFiles/beman.exemplar_verify_interface_header_sets.dir/Release/beman.exemplar_verify_interface_header_sets/beman/exemplar/identity.hpp.cxx.o
CMake Error at build/src/beman/exemplar/cmake_install.cmake:44 (file):
  file cannot create directory: /opt/beman.exemplar/include/beman/exemplar.
  Maybe need administrative privileges.
Call Stack (most recent call first):
  build/cmake_install.cmake:42 (include)


Error: Process completed with exit code 1.

$ ls -l / | grep /opt
drwxr-xr-x   7 dariusn root       4096 Nov 12 07:38 opt

I guess it depends if and how you have configured /opt. So we may add:

# Create the /opt directory if it doesn’t already exist
sudo mkdir -p /opt

# Change ownership of /opt to the current user
sudo chown -R $USER /opt

(check other existing commands, sudo may not be required!)

I would use ${PWD}/stagedir like boost does.
I would keep the current PR just for adding MAC OS support. We can discuss on discourse (https://discourse.bemanproject.org/latest) in a new post if /opt is or not the best path to recommend to install in docs, etc CI. So I'm OK with changing it, but the flow should be:

• discourse thread and get a vote
• add a recommendation into Beman docs (beman/ repo)
• the propagate to ALL repos (their config and docs)
  We should aim to have the same default path in all places/repos! (docs, CI files, etc). It just makes the usability simpler for new users! And it still allows folks to use other custom install path on own system!

It does not successfully run on Darwin if we install to /opt?

As a user of project, I want to have control if and where the binaries are installed!

I am not willing to change more.

/opt is the correct location in a unix FHS style system because every other prefix is owned by someone else. / and /usr (now fused anyway) are owned by the OS distro, /usr/local is the machine admin, ~ and ~/.local are user controlled.
https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES

"A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where is a name that describes the software package and is the provider's LANANA registered name."

So a todo to register beman with LANANA, although it's actually unlikely real world installs go there.

Testing install in CI is also not locking in an install location for any user. PREFIX is controlled by the installer.

That all said, outside of a scratch VM like a GitHub action runs in, using a directory inside out root, but outside the source tree, like we do for build, is the friendly way to do it.

Staging isn't the right name, because it's not going anywhere after that. Trying to do a package manager's job is a mistake

As a user of project, I want to have control if and where the binaries are installed!

I am not willing to change more.
@ClausKlein , I agree with you, as a user you can install them anywhere you want. As a developer inside the Beman project, you must use some requirements/recommendations/best practices used inside the Beman org. That's not questionable, but you are more than welcome to propose to change / upgrade/ improves these sets of standards or practices.

TLDR:

• This CI config is exclusively for internal development. It must follow our internal practices or rules.
• Similarly, examples for root README.md, are just examples and our recommendations. Our choice, but not an obligation for users.
• Any user can install our libraries in a custom path, that's for sure an available option!

Steve also explained this in previous comment - "Testing install in CI is also not locking in an install location for any user. PREFIX is controlled by the installer."

I hope that is clear now. Please revert the changes related to the install path. Thanks!