Skip fetch only works when `CPM_SOURCE_CACHE` is defined

[ScottBailey]

When the environment variable CPM_SOURCE_CACHE is set, re-running cmake does not cause a fetch and patch.

When unset, fetch and patch both occur.

The problem observed (see #572 for more discussion) is that the unset path fetch does not overwrite the source and so the patch command fails.

#572 suggests a fix that could ignore errors during patching. I think this could be an issue when a user is testing version updates; it would be nice if we just, say, updated package A to latest version and running CMake told us the patches were incompatible/not applied. I don't think -t reports that?

In my testing, I see that when the environment variable is set, we skip the fetch and patch steps. Maybe we can add a cache variable to indicate the initial fetch and patch skips were successful?

Recreation of this is relatively simple, see https://github.com/ScottBailey/cpm-cmake-test-577 for an automated working example.

@lemire

[wolfpld]

A simple solution seems to be to always enable the cache.

--- a/cmake/CPM.cmake
+++ b/cmake/CPM.cmake
@@ -154,7 +154,7 @@ set(CPM_DRY_RUN
 if(DEFINED ENV{CPM_SOURCE_CACHE})
   set(CPM_SOURCE_CACHE_DEFAULT $ENV{CPM_SOURCE_CACHE})
 else()
-  set(CPM_SOURCE_CACHE_DEFAULT OFF)
+  set(CPM_SOURCE_CACHE_DEFAULT ${CMAKE_CURRENT_BINARY_DIR}/.cpm-cache)
 endif()
 
 set(CPM_SOURCE_CACHE

[lemire]

Intriguing.

[julianoes]

Would be nice to have some sort of fix for this.

One option would be to do a git checkout . before every patch, at least for the case where there CPM_SOURCE_CACHE_DEFAULT is not set.

[ScottBailey]

Would be nice to have some sort of fix for this.

One option would be to do a git checkout . before every patch, at least for the case where there CPM_SOURCE_CACHE_DEFAULT is not set.

I'd love to see this fixed myself. I started working on it, but it's a significant time investment for me. I've done the leg work to easily, repeatable recreate the defect and was hoping someone else might lend a hand. I may have time over the holidays to look deeper into this, but I'm not gonna hold my breath.

If you dig into this, I think you'll find significant complexity around this problem. Enough that a quick fix isn't likely to happen. Still, I'd appreciate someone else taking a look and providing feedback.

[lemire]

@ScottBailey What do you think of @wolfpld's solution?

[ScottBailey]

@ScottBailey What do you think of @wolfpld's solution?

I feel like this is unexpected behavior? I think it's better for the end user to decide how to work around this problem rather than band-aid the repo.

The actual defect is probably an easy fix as we can trace the path between working and failing and compare them. Someone just needs to have the time to do it.

[lemire]

I feel like this is unexpected behavior?

Here is how I view things.

We have two code paths. One that were the cache location is set. This code path works.

We have another code path where the cache location is not set. This code path is broken.

The fix is to have just one code path. If the cache location is not set, we just set it. This drops the broken code path and solves the problem... further simplifying the logic.

That is, that the code is so complicated is part of the bug. Why is it so difficult to understand what is going on?

[ScottBailey]

As a counter, the code path without a cache in fact works except when a patch is added. If we force a cache path we reduce functionality for others. And if we make a band-aid fix we increase technical debt. Like you, I am just a contributor, not a maintainer. But were I a maintainer I don't think I'd want to take a patch that increased technical debt.

Frankly, I've been hoping I'd done enough prep work to make this an easy fix for someone else. And I think it should be an easy fix, just a little time consuming to compare the traces.

[lemire]

(I also have no power here. I am just a user.)

If we force a cache path we reduce functionality for others.

Concretely, what would be lost?

But were I a maintainer I don't think I'd want to take a patch that increased technical debt

How does the patch proposed by @wolfpld increases the technical debt?

My point above is that it reduces the technical debt by reducing the number of code paths.