Remove experimental C++ import from CMakeLists

[mccakit]

UUID must be set at CMAKE_TOOLCHAIN_FILE

[DockedFerret800]

I think it is better to replace that with set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD "_string_" CACHE STRING "") or even better with set(CACHE{CMAKE_EXPERIMENTAL_CXX_IMPORT_STD} VALUE "_string_") from CMake 4.2.

[mccakit]

I disagree, that is just hard to read.
Just notify the users they have to set the UUID before configure.
That's their responsibility

[DockedFerret800]

Why exactly is it hard to read? I just don’t understand why we should put additional pressure on the user by requiring them to take more actions when that makes absolutely no sense. The same approach is used in every major project with modules.

[mccakit]

Because set(CACHE{CMAKE_EXPERIMENTAL_CXX_IMPORT_STD} VALUE "_string_") is not a valid thing.
CMake expects a valid string there, That the user should know, by checking the cmake uuid values for their version.

[DockedFerret800]

I replace an actual string with _string_ in the examples above because I don't remember the string for the latest CMake version. Obviously it should be replace with an actual one.

[mccakit]

The users can't edit every single project they build. It just makes sense they set UUID at toolchain level or pass it via args like -Detc. There are multiple uuid's, I will also add CPS support in another that will require another UUID. It makes sense it is set at toolchain level

[DockedFerret800]

If we use the approach proposed above, set with an up-to-date string, users won't have to override it most of the time. When they actually need to, they can override with -D or in any other way. Right now you're proposing to put an extra step for all users, which is just an unnecessary overcomplication of things.

[mccakit]

You assume everyone compiling the project will use the same cmake version.
Please do remember even UUID's from CMake 4.3.4 and 4.4 is different.
So updating UUID's at project level is a fool's errand, because they constantly update it.

Also it isn't like stuff remain experimental for a little bit. Import std is experimental for at least the last 2 years. With god knows how many UUID's

[DockedFerret800]

Once again, your approach proposes that the user needs to specify a string every time. In the approach proposed above that is used in most modules projects, the user still has the ability to override, but only when there is an actual need to. You are proposing to make this a mandatory step, whilst it shouldn't be one.

[mccakit]

Sure, you can do that. But it is a waste of time. In the end same amount of effort is needed.
If you like you can edit my PR or close this and create a new one

[DockedFerret800]

I don't get how this is a waste of time, if the need to manually specify the string is guaranteed to be lower

[mccakit]

CMake UUID's change every month, %95 of the users will have to set it via toolchain files or -Dopts anyway.

[DockedFerret800]

You said "95% of users", which is lower than a 100%. How is this a "waste of time"?

[DockedFerret800]

Furthermore, CMake import std string does not change every month. The reason for a change in 4.4 was that they took it out of experimental, it didn't work, and they had to return it, which means regenerating a string.

[mccakit]

If you care so much about the convenience of the minority, I can't argue about that, it is a matter of preference.
Either way, your solution also does the job, I don't care which one passes

[DockedFerret800]

#11

[stephenberry]

Thanks for raising this — the underlying problem was real, and it did bite us. Pinning lukka/get-cmake moved CI from CMake 4.3.3 to 4.4.1, and since 4.4 rotated the UUID, the hardcoded 4.3 value failed to configure exactly as you'd predict.

We went with a third option in #9: a table keyed on the running CMake version, so the correct UUID is selected automatically and unknown releases fall through to a diagnostic instead of a wrong value.

That preserves the property you were arguing for — no single hardcoded UUID that goes stale — without requiring every consumer to supply one. On the disagreement in this thread, I think you were both right about different things: your point that the UUID can't be pinned to one release was correct, and @DockedFerret800's point that most consumers shouldn't have to supply it was also correct. The table satisfies both.

One thing worth knowing: the toolchain-file workflow you describe already works, unmodified. A toolchain file is read during project(), after the lines that set the gate, so it takes precedence. I verified this:

-- AFTER project: 'TOOLCHAIN-VALUE'

The mechanism that was genuinely blocked is -D — a plain set() shadows the cache entry -D creates, so it was being silently discarded. That's fixed in #12.

Your CPS work is unaffected either way, since CMAKE_EXPERIMENTAL_FIND_CPS_PACKAGES is a separate variable — happy to see that PR when it's ready.

Closing this as superseded by #9 and #12, but the diagnosis in it was sound and directly shaped where we landed. Thanks.