FetchContent_Declare() UPDATE_DISCONNECTED and vcpkg

Code
1

After upgrading to CMake 3.30 simple FetchContent_Declare() doesn’t work anymore with the vcpkg toolchain file used.

My CI pipelines started failing like this.

Here is the actual code.

I’m replacing the GIT_TAG with the commit ID inside my GitHub actions, so at the end of the day it looks like this:

FetchContent_Declare(TinyOrm
    GIT_REPOSITORY https://github.com/silverqx/TinyORM.git
    GIT_TAG        5c0bce878777d02bcacefe7d7309e8e1a0b88eb6
    OVERRIDE_FIND_PACKAGE
)

I don’t understand why this is happening, I know that the vcpkg internally sets UPDATE_DISCONNECTED (somewhere/somehow) but I would expect that my FetchContent commands will work.

As you can see I’m using OVERRIDE_FIND_PACKAGE to make the fetchcontent-ed project available during the find_package(TinyOrm) call, until 3.30. :thinking:

What am I doing wrong? Thx for any advice.

2

Looks like you must have also updated the project, since the first line now starts with:

cmake_minimum_required(VERSION 3.22...3.30 FATAL_ERROR)

So we can eliminate some things from the discussion, can you please change that line back to whatever it was before. The 3.30 would have to have been some older CMake version. If you made any other changes to the project, ideally undo those as well so that the only thing changing will be the version of CMake used in the CI job. Once you’ve reverted those changes, please try re-running the same job as before (i.e. still using CMake 3.30) and post the results.

3

Nothing changed as you can see from the commit history, the only thing that was changed was the CMake policy max. version from 3.29 to 3.30, I always want to use all the new CMake policies to make sure I’m compatible.

Which CMP do you think can cause this, only one I see is CMP170 but it talks about the FETCHCONTENT_FULLY_DISCONNECTED and not about UPDATE_DISCONNECTED, are these two settings somehow related?

The following isn’t true, read also the next post.

I’m pretty sure the CI pipeline finishes successfully with CMake max. version set to 3.29.

Here is the Revert and here is the re-invoked CI pipeline.

4

Ok, now it starts to be a little messy :grin:, everything about Reverting the CMake max. version to 3.29 isn’t true as I reverted it for the wrong HelloWorld example project (I have two) :blush:.

As you can see there were two CI pipeline launches, the first one failed again, that was with 3.30 max. version and the same build folders (I’m not deleting build folder to have faster rebuilds, this CI pipeline is running on selfhosted GH runner, and is the same problem I have described in the first post).

The second run (I manually reinvoked this failed run) was also with max. version 3.30 but I deleted all build folders and as you can see it finished successfully.

So no revert to CMake max. 3.29 happened at all and it finished successfully after manually deleting the build folders.

I screwed it up, sry about this.

5

Here is the CI pipeline run with the second HelloWorld example (on which I reverted the CMake max. version to 3.29 but didn’t invoke it), and this run is with max. version 3.30 with deleted build folders and it finished successfully.

So from my view this problem happened if I upgraded max. version from 3.29 to 3.30, with CMake 3.30 and build folders from cmake 3.29.

I think no need to put more effort into it from my side to reproduce it.

6

Ok, now I discovered that the problem is more serious because I must always delete the build folder to avoid this problem. Even if the build folder was created by the CMake 3.30.

So I tried to decrease the max. CMake version to 3.29 as you proposed (this time I didn’t screw it) and the build was successful.

Is this an expected behavior or a bug?

7

I invested ~6 hours to debug this line by line and here is what I have found.

Setting the set_property(DIRECTORY PROPERTY EP_UPDATE_DISCONNECTED ON/OFF) has no effect, setting the -DFETCHCONTENT_UPDATES_DISCONNECTED:BOOL=OFF/ON or -DFETCHCONTENT_UPDATES_DISCONNECTED_TINYORM:BOOL=OFF/ON has no effect.

I don’t know if setting FETCHCONTENT_UPDATES_DISCONNECTED/_XYZ should work or not.

But setting the set_property(DIRECTORY PROPERTY EP_UPDATE_DISCONNECTED ON/OFF) must work as is described in the docs to populate the default value.

The reason why the EP_UPDATE_DISCONNECTED doesn’t work is, that the can_fetch_default is initialized too late and isn’t available for the _ep_write_gitupdate_script() command that needs it a few lines above, the configure_file() that needs it is here and the template file where the value should be used is here.

I tried to move this can_fetch_default init. logic above the _ep_write_gitupdate_script() command and everything started working, not only the EP_UPDATE_DISCONNECTED, but now I can control these updates by the FETCHCONTENT_UPDATES_DISCONNECTED/_XYZ option/s.

I want to tell that isn’t fully possible to understand code like this in a few hours and also there is a lot of written in the docs.

8

Thanks for the analysis, your assessment is correct. I’ve opened a new bug report for this, and a fix should be following shortly.

1 Like