apr: allow recipes which support cross_building to consume exising apr binaries

[puetzk]

Since conancenter only provides x86_64 binaries on windows, it's frequently for necessary for an overall build which uses --settings:host arch=x86 --build missing to produce 32-bit requires from conancenter recipes to need --settings:build=x86-64 in order to satisfy tool_requires.

There are cross_building scenarios apr can't support, but that one would be fine, the current recipe validation is just stricter than it needed to be.

---

• I've read the contributing guidelines.
• I've used a recent Conan client version close to the currently deployed.
• I've tried at least one configuration locally with the conan-center hook activated.

[puetzk]

Do not raise ConanInvalidConfiguration from build() method. Please, move that same check to validate() method.

The ConanInvalidConfiguration is not in build(), it's in validate_build(). This is what the docs recommend: https://docs.conan.io/2/reference/conanfile/methods/validate_build.html#validate-build and I find several other examples in conan-center-index:

• cmake: use validate_build to reflect invalid build configurations #16179
  

  conan-center-index/recipes/cmake/3.x.x/conanfile.py

  Lines 43 to 45 in c927e78

  	def validate_build(self):
  	if self.settings.os == "Windows" and self.options.bootstrap:
  	raise ConanInvalidConfiguration("CMake does not support bootstrapping on Windows")

• moltenvk: add 1.1.11 & 1.2.0 + conan v2 support + shared by default + add hide_vulkan_symbols option #13142
  

  conan-center-index/recipes/moltenvk/all/conanfile.py

  Lines 116 to 119 in c927e78

  	def validate_build(self):
  	spirv_cross = self.dependencies["spirv-cross"]
  	if spirv_cross.options.shared or not spirv_cross.options.msl or not spirv_cross.options.reflect:
  	raise ConanInvalidConfiguration(f"{self.ref} requires spirv-cross static with msl & reflect enabled")

Any idea what the bot's objecting to, or a more detailed log?

[puetzk]

Found the more detailed logs, and he failures came back from "[required] apr/1.7.0@ macOS, Clang (M1/arm64)", specifically https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/c3i/misc/logs/pr/16782/1-configs/macos-m1-clang/apr/1.7.0//summary.json

Which seems to have worked as intended. To pick on one specific example, it was trying to cross-compile from x86_64 to armv8
https://c3i.jfrog.io/c3i/misc/logs/pr/16782/1-configs/macos-m1-clang/apr/1.7.0//172c221ccbd15188b78586021201c31d32ead0b1-build.txt

and was told it can't:

Cross-build from 'Macos:x86_64' to 'Macos:armv8'
Installing (downloading, building) binaries...
ERROR: There are invalid packages (packages that cannot exist for this configuration):
apr/1.7.0: Cannot build for this configuration: apr recipe doesn't support cross-build yet due to runtime checks in autoconf

This wasn't in build() - unlike the successes, there's no "apr/1.7.0: Calling build()" message printed like there is for ones that could be built, because vaidate_build() failed first.

These same configurations show INVALID_CONFIGURATION in e.g. #14797 https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/c3i/misc/logs/pr/14797/5/apr/1.7.0//summary.json. As expected, given that apr indeed cannot cross-compile.

So it seems like the difference has got to be something that changed about c3i?

[puetzk]

Oh duh, it's probably just picking up on the fact that armv8-Macos-clang binaries would now be allowed to exist, even though c3i still can't build them, since it only has a cross-compiler agent and not a native apple silicon one). So now it tried, and failed.

So apparently whatever implements this check:

Do not raise ConanInvalidConfiguration from build() method. Please, move that same check to validate() method.

Must have evaluated the graph ahead of time and pruned INVALID_CONFIGURATION, but either it ignored graph.Node.cant_build, or did that preliminary evaluation of the graph (deciding which package_ids to attempt building) without specifying --profile:build (and thus the recipe didn't know that it was going to be a cross-compile). Since c3i is closed-source I'm not sure how to distinguish those, or how to fix it...

[puetzk]

Nevermind, the old code (in validate(), knew it was cross-compiling, so --profile:host was set. So it must be that c3i doesn't prune based on cant_build (i.e. invalid_build/invalid_build_reason if it's using the conan info json output...)

[ghost]

I detected other pull requests that are modifying apr/all recipe:

• [APR] Upgrade to 1.7.4 #17323

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[AbrilRBS]

Raising InvalidConfiguration from valida_build, retriggering the PR now, thanks a lot for your patience :)

[conan-center-bot]

Conan v1 pipeline ✔️

All green in build 4 (5a0df8404430914311570688d52af1c0472c0016):

• apr/1.7.0@:
  All packages built successfully! (All logs)

---

Conan v2 pipeline ✔️

Note: Conan v2 builds may be required once they are on the v2 ready list

All green in build 2 (5a0df8404430914311570688d52af1c0472c0016):

• apr/1.7.0@:
  All packages built successfully! (All logs)

[AbrilRBS]

@puetzk thanks a lot for your contribution and patience while we implemented the necessary logic in the CI to handle cases like this, sorry that we did not communicate properly that work was underway to have this PR merged. Also, thanks for such a detailed investigation and description of the problem, it has helped a lot when reviewing the change itself!