Order of CPMAddPackage matters?

[christianparpart]

Hey,

I just recently have received a contribution to migrate from FetchContent to CPM.

The PR at contour-terminal/contour#313 was also tested by @data-man and confirmed to work, whereas for me (different OS at least) when starting up the CPM managed executable it did cause a SEGV at YAML::LoadFile(), at some place that absolutely did not make sense (not even valgrind was helpful).

Then I found a fix by simply reordering the CPMAddPackage() commands, see contour-terminal/contour#315.

I am new to CPM and assumed it to be a little bit more declarative, at lesat in a sense that these CPMAddPackage are consecutively listed should not make any difference in terms of order.

Now, I am not sure if it is wrong use from our side or a dependency-related bug on CPM side. But I'd like to understand why this is happening.

Best regards,
Christian Parpart.

[TheLartians]

Hey Christian,

Thanks for the question!

That is indeed very strange behaviour and hard to say what the cause is. In general, the order in which you declare dependencies can matter, as it defines the order in which their CMake scripts are loaded. For example, if a dependency changes the global CMake state, then it will be changed for all decencies included afterwards. However, for well written dependencies the global state should not be modified in a meaningful way, so there should be no difference. This should be the exact same behaviour as with using regular FetchContent, by the way.

One thing to note is that CPM will not add a dependency that has been added before, e.g. if you add A, B and then A again, the second inclusion of A will be ignored, as it would otherwise create duplicate libraries.

[TheLartians]

An unrelated thing I noticed when skimming through the PR was that you have copied the development version of CPM.cmake into your repo. This is not recommended, as it bloats your repo, could contain broken / untested features and also will is more difficult to update as it does not contain a valid version identifier. I'd also recommend replacing the full CPM.cmake script with the short get_cpm.cmake script from a recent release.

The quickest way to do this or to update to the most recent version would be running the following bash command from your project's root directory.

wget -O cmake/CPM.cmake https://github.com/cpm-cmake/CPM.cmake/releases/latest/download/get_cpm.cmake

[christianparpart]

Oh, yes, you are right. it should have been latest stable release at least. I am using CPM due to a contribution, so I do not know much about CPM yet.
But one major problem i see with the get_cpm.cmake approach is, that you may have non-deterministic builds, as the outcome of your package might depend on the time your package has been built (and CPM has been pulled). Using the latest stable though I think is definitely something I have to adapt to. Thanks :)

[TheLartians]

Always happy to help!

FYI get_cpm.cmake should also be deterministic, as it always refers to a stable release as defined by the CPM_DOWNLOAD_VERSION variable in the script. So I'd definitely consider it if you want to avoid code bloat in your repo. :)