proj: add v9.4.0, drop old versions

[valgur]

• Resolves PROJ 9.4.0 #23482.

[SpaceIm]

Sorry I don't see the point of this modification of patches. I prefer to have patches per version instead of an external cmake file injected to some magic line in upstream CMakeLists. It's hard to reason about CMake logic with this kind of external cmake file.
Currently we just have to maintain a small patch, is it really a big deal? Why not just submit a PR upstream (by defining SQLite::SQLite3 target in FindSqlite3.cmake, and link to this target), so that we won't need a patch anymore.

Patches are better when fixes can be submitted upstream, because it doesn't require any modification in conanfile when it's fixed upstream. With your pattern, it's worse for maintenance, because we will have to remove all this logic in conanfile conditionally once fixed upstream...

[ErixenCruz]

PROJ will use SQLite::SQLite3 target in next release. that is when the patches can be removed.

[AbrilRBS]

Thanks!

[perseoGI]

Hi @valgur, thanks for your contribution!
PROJ 9.4.1 was released 5 days ago: OSGeo/PROJ@9.4.0...9.4.1
Maybe we can use this PR to add the latest.

[valgur]

PROJ 9.3.0 and older set cmake_minimum_required(VERSION 3.9) which in turn sets CMP0077 to OLD by default. This line ensures that tc.variables[] works as expected in all cases.

[valgur]

This line is very likely useless (or if it is planned to drop this logic

in all recipes, it should live in conan client code I guess, but again it's useless for properly formed CMakeLists since conan toolchain translates tc.variables to CACHE variables, therefore CMP0077 doesn't matter). You are misunderstanding the issue being fixed by CMP0077 in some important ways. When it’s set to OLD, all set(CACHE) and option() commands in CMakeLists.txt will overwrite the value previously set by CMakeToolchain, causing them to be ineffective. There is no such thing as a properly-formed CMakeLists.txt in this case - only the value of this policy matters. Believe me, this is a very real issue or at least a potential pitfall in many recipes. I encourage you to test it yourself, if you’re having doubts. I have been adding it for all recipes where CMake policy version is configured to 3.11 or older, just in case. Even if these projects might not be setting CACHE vars in the current version, they easily can switch to using them in later versions, which is very easy to miss. I agree that this would be better handled by the Conan client, but I suppose setting it by default for all projects might cause unexpected regressions in unrelated places, making it a bit risky. And even then it would take a while for the change to become effective for CCI.

…

On Thu, Jun 6, 2024 at 21:40 SpaceIm ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In recipes/proj/all/conanfile.py <#21512 (comment)> : > @@ -109,6 +110,7 @@ def generate(self): # Workaround for: conan-io/conan#13560 libdirs_host = [l for dependency in self.dependencies.host.values() for l in dependency.cpp_info.aggregated_components().libdirs] tc.variables["CMAKE_BUILD_RPATH"] = ";".join(libdirs_host) + tc.cache_variables["CMAKE_POLICY_DEFAULT_CMP0077"] = "NEW" Looking at conancenter history, I see this policy injected more & more quite randomly without rational. It's quite misleading. — Reply to this email directly, view it on GitHub <#21512 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANSD4C3IRCNPGG2HWBDGLDZGCUKHAVCNFSM6AAAAABABGW4K2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCMBSHEZDEMJYGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[perseoGI]

LGTM

[perseoGI]

LGTM

[conan-center-bot]

Conan v1 pipeline ✔️

All green in build 17 (bc31fb1a772701c1bba82c29c4c6cc5713dd67ba):

• proj/9.4.1:
  All packages built successfully! (All logs)

• proj/9.3.0:
  All packages built successfully! (All logs)

• proj/9.3.1:
  All packages built successfully! (All logs)

• proj/9.2.1:
  All packages built successfully! (All logs)

• proj/7.2.1:
  All packages built successfully! (All logs)

• proj/6.3.1:
  All packages built successfully! (All logs)

• proj/8.2.1:
  All packages built successfully! (All logs)

---

Conan v2 pipeline ✔️

Note: Conan v2 builds are now mandatory. Please read our discussion about it.

All green in build 16 (bc31fb1a772701c1bba82c29c4c6cc5713dd67ba):

• proj/9.3.1:
  All packages built successfully! (All logs)

• proj/9.4.1:
  All packages built successfully! (All logs)

• proj/6.3.1:
  All packages built successfully! (All logs)

• proj/9.2.1:
  All packages built successfully! (All logs)

• proj/9.3.0:
  All packages built successfully! (All logs)

• proj/8.2.1:
  All packages built successfully! (All logs)

• proj/7.2.1:
  All packages built successfully! (All logs)