[boost-cobalt] Throw error in the configure step when the compiler is not supported

[JackBoosY]

Fixes #40290 #40310 #39573 #39495 #38498

[JackBoosY]

Since the upstream has no willing to fix this (boostorg/cobalt#215), I prefer to make this changes here.

[JackBoosY]

Discussion: as I commented on Discord, should we add a vcpkg function to pre-check the current compiler whether it is supported for the current port?

[dg0yt]

It is not necessary to patch each individiual check. It is enough to raise a fatal error instead of the top-level return(), https://github.com/boostorg/cobalt/blob/cd2ea28a53e1f4f9f77ff962207b95358c2074db/CMakeLists.txt#L17

[dg0yt]

should we add a vcpkg function to pre-check the current compiler whether it is supported for the current port?

This would require

• to run CMake before the actual build
• to duplicate the package's checks.

This doesn't make sense IMO.
(What still makes sense is better forwarding of error message from configuration to the console. But that is a different, old, story.)

[JackBoosY]

This would require

• to run CMake before the actual build
• to duplicate the package's checks.

This doesn't make sense IMO. (What still makes sense is better forwarding of error message from configuration to the console. But that is a different, old, story.)

Although the compiler will be checked twice, this will avoid returning errors after several minutes or even tens of minutes of build time.

The way I think about it, the compiler will be checked before all the port build, and first check if all the ports in the build list support this compiler version, just like if triplet is supported.

[dg0yt]

Although the compiler will be checked twice, this will avoid returning errors after several minutes or even tens of minutes of build time.

Checking during CMake configuration is before the build, not after several minutes.

[JackBoosY]

Although the compiler will be checked twice, this will avoid returning errors after several minutes or even tens of minutes of build time.

Checking during CMake configuration is before the build, not after several minutes.

Not needed, this step can be executed in vcpkg binary, the port vcpkg.json can add a new keyword such like compiler: msvc>=x.y.z, gcc>=a.b.c.

[dg0yt]

Not needed, this step can be executed in vcpkg binary, the port vcpkg.json can add a new keyword such like compiler: msvc>=x.y.z, gcc>=a.b.c.

The compiler ID and and version knowledge is in the CMake toolchain (project mode), not even in the triplet files (script mode). It might be possible to pull some properties into the tool while hashing the compiler binary, but I don't think it is comming soon. I also wonder how well this would scale over all possible compilers and versions. Once somebody adds a fancy-c++>=1.2.3, most of us will be unable to update this expression.

(What we would really need in supports is the deployment target (android-24, macOS 14.4, Windows 10). At least this is responsible for a lot of ci.baseline.txt entries.)

[JackBoosY]

The compiler ID and and version knowledge is in the CMake toolchain (project mode), not even in the triplet files (script mode). It might be possible to pull some properties into the tool while hashing the compiler binary, but I don't think it is comming soon. I also wonder how well this would scale over all possible compilers and versions. Once somebody adds a fancy-c++>=1.2.3, most of us will be unable to update this expression.

(What we would really need in supports is the deployment target (android-24, macOS 14.4, Windows 10). At least this is responsible for a lot of ci.baseline.txt entries.)

Anyway, this will not be implemented in this PR.

[jimwang118]

If the compiler does not support it, should we keep the return and add an error message before the return?

[JackBoosY]

If the compiler does not support it, should we keep the return and add an error message before the return?

Already do that.

[jimwang118]

Already do that.

The patch appears to have simply removed the return and replaced it with an error message.

[dg0yt]

Skipping all nitpicks.

[JackBoosY]

The patch appears to have simply removed the return and replaced it with an error message.

Correct, the origin logic is just return and pass configure step, which should be throw an error message instead, which is my changes.

[JavierMatosD]

@JackBoosY, all boost ports must be updated through the scripts/boost/generate-ports.ps1

To correctly add a patch to a boost port:

1. Place the patch file in the port’s directory.
2. Bump the port’s version in the $portVersions section of the generate-ports.ps1 script.
3. Execute the script to regenerate the portfiles.

[JackBoosY]

@JavierMatosD Use this command will remove port-version in vcpkg.json, so I didn't commit that.

never mind that.

[JavierMatosD]

This will break users who vcpkg install boost with a compiler without these features. I think the boost port should drop the dependency on boost-cobalt

[JackBoosY]

Why? boost-cobalt is still a part of full boost. If the compiler is not supported, I think throw configure error is expected.

[dg0yt]

Throw-error is expected for boost-cobalt, but not so much for an uninformed vcpkg install boost. An optional feature might be a middle way, as already exists for mpi.