MPFR: partial Conan 2.0 Compatibility

[System-Arch]

Specify library name and version: mpfr/4.1.0

Migrated recipe to Conan 2.0. Resolves #14666. Note that these changes are untested on Windows with Conan 2.0 because some of the required dependencies don't build with 20 yet

---

• I've read the contributing guidelines.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the conan-center hook activated.

[github-actions]

Hooks produced the following warnings for commit ecf6011

mpfr/4.1.0

post_package(): WARN: [APPLE RELOCATABLE SHARED LIBS (KB-H077)] install_name dir of these shared libs is not @rpath: libmpfr.dylib, libmpfr.6.dylib

mpfr/4.0.2

post_package(): WARN: [APPLE RELOCATABLE SHARED LIBS (KB-H077)] install_name dir of these shared libs is not @rpath: libmpfr.dylib, libmpfr.6.dylib

[prince-chrismc]

After some length discussion...

Because this code path is not tested but CI, it's very likely to break in subsequent PRs - it has a higher risk of negatively impacting the larger consumers base (to the benefits of only a few). It adds a burden to the reviewers and maintainers to make future changes. We, are willing to accept some extra effort for individual contributors as long as it prevents pain on the larger community.

---

Our recommendation for user who need to build from Git source with CCI recipes is to git archive the commit then and pull those in with a entry in conandata.yml such that the normal workflow is preserved.

[prince-chrismc]

Please remove this option and the extra dependencies 🙏

[System-Arch]

Hi @prince-chrismc,

Thanks for your feedback. Certainly, I will do as you request (and we will maintain a private fork of the recipe to meet our needs), but I wanted to clarify a couple of points:

1. These changes work even without using Git source. They simply enable the regeneration of the configure script and Makefiles from their .ac and .in templates. AutotoolsToolchain even has a method for this: Autotools::autoreconf().
2. It is unclear to me how the "git archive" approach would work unless one first runs autoreconf manually before archiving the resulting build area. The benefit of the pending change is that it leverages Conan to automatically ensure one has a self-consistent version of the autotools (autoconf, automake, libtool, etc.) needed to actually be able to run autoreconf to create configure and Makefiles from Git source. In jettisoning this code, CCI is loosing that information and tooling.
3. I think this use case points out an opportunity for a Conan enhancement, which is the ability to add tags to patches in the conandata.yml file. Such a feature would permit selective application of patches on an as needed basis. For example, apply_conandata_patches applies Windows-specific patches regardless of what platform it is running on. Had such a feature existed, I would have used it to selectively apply the autogen patches.
   Thanks

[prince-chrismc]

Please remove this logic and the subsequent autogen

[System-Arch]

Removed, but please see message above about how an enhancement to apply_conandata_patches would have made this cleaner.

[uilianries]

Looking really good, just a comment about test_v1_package

[uilianries]

LGTM

[SpaceIm]

It's doesn't pass v2 pipeline for the moment, while claiming to be v2 compatible.

[prince-chrismc]

This has a lot of good work so I will give it a tick, we can polish the 2.0 to pass in the next PR :)

[conan-center-bot]

Conan v1 pipeline ✔️

All green in build 44 (1a61172d261a1daffd18290efd7f4bce965cf4d8):

• mpfr/4.1.0@:
  All packages built successfully! (All logs)

• mpfr/4.0.2@:
  All packages built successfully! (All logs)

---

Conan v2 pipeline (informative, not required for merge) ❌

Note: Conan v2 builds are informative and they are not required for the PR to be merged.

The v2 pipeline failed. Please, review the errors and note this will be required for pull requests to be merged in the near future.

See details:

Failure in build 47 (1a61172d261a1daffd18290efd7f4bce965cf4d8):

• mpfr/4.1.0@:
  CI failed to create some packages (All logs)

  Logs for packageID 120b68957e77b6ca66ea506daddd9511347758da:

  [settings]
  arch=x86_64
  build_type=Release
  compiler=gcc
  compiler.cppstd=gnu17
  compiler.libcxx=libstdc++11
  compiler.version=11
  os=Linux
  [options]
  */*:shared=True
  

  [...]
  -------- Installing package mpfr/4.1.0 (2 of 2) --------
  mpfr/4.1.0: Building from source
  mpfr/4.1.0: Package mpfr/4.1.0:120b68957e77b6ca66ea506daddd9511347758da
  mpfr/4.1.0: Copying sources to build folder
  mpfr/4.1.0: Building your package in /home/conan/w/prod-v2/BuildSingleReference/p/t/mpfr72e98faa33b91/b
  mpfr/4.1.0: Calling generate()
  mpfr/4.1.0: Generators folder: /home/conan/w/prod-v2/BuildSingleReference/p/t/mpfr72e98faa33b91/b/build-release/conan
  mpfr/4.1.0: Generating aggregated env files
  mpfr/4.1.0: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
  mpfr/4.1.0: Calling build()
  mpfr/4.1.0: Apply patch (portability): Windows header DLL
  mpfr/4.1.0: Calling:
   > "/home/conan/w/prod-v2/BuildSingleReference/p/t/mpfr72e98faa33b91/b/src/configure" --enable-shared --disable-static --prefix=/ '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' --enable-thread-safe --with-gmp=/home/conan/w/prod-v2/BuildSingleReference/p/gmp4efe3e83e00c3/p 
  mpfr/4.1.0: RUN: "/home/conan/w/prod-v2/BuildSingleReference/p/t/mpfr72e98faa33b91/b/src/configure" --enable-shared --disable-static --prefix=/ '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' --enable-thread-safe --with-gmp=/home/conan/w/prod-v2/BuildSingleReference/p/gmp4efe3e83e00c3/p 
  checking for a BSD-compatible install... /usr/bin/install -c
  checking whether build environment is sane... yes
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  checking for gawk... no
  checking for mawk... mawk
  checking whether make sets $(MAKE)... yes
  checking whether make supports nested variables... yes
  checking whether to enable maintainer-specific portions of Makefiles... yes
  checking build system type... x86_64-pc-linux-gnu
  checking host system type... x86_64-pc-linux-gnu
  checking for grep that handles long lines and -e... /bin/grep
  checking for egrep... /bin/grep -E
  checking for a sed that does not truncate output... /bin/sed
  checking whether configure options are compatible... yes
  checking for gcc... gcc
  checking whether the C compiler works... yes
  checking for C compiler default output file name... a.out
  checking for suffix of executables... 
  checking whether we are cross compiling... configure: error: in `/home/conan/w/prod-v2/BuildSingleReference/p/t/mpfr72e98faa33b91/b/build-release':
  configure: error: cannot run C compiled programs.
  If you meant to cross compile, use `--host'.
  See `config.log' for more details
  
  mpfr/4.1.0: ERROR: 
  Package '120b68957e77b6ca66ea506daddd9511347758da' build failed
  mpfr/4.1.0: WARN: Build folder /home/conan/w/prod-v2/BuildSingleReference/p/t/mpfr72e98faa33b91/b/build-release
  *********************************************************
  Recipe 'mpfr/4.1.0' cannot build its binary
  It is possible that this recipe is not Conan 2.0 ready
  If the recipe comes from ConanCenter check: https://conan.io/cci-v2.html
  If it is your recipe, check if it is updated to 2.0
  *********************************************************
  
  ERROR: mpfr/4.1.0: Error in build() method, line 148
  	autotools.configure() # Need to generate Makefile to extract variables for CMake below
  	ConanException: Error 1 while executing
  

• mpfr/4.0.2@:
  Didn't run or was cancelled before finishing

---

^{Note: To save resources, CI tries to finish as soon as an error is found. For this reason you might find that not all the references have been launched or not all the configurations for a given reference. Also, take into account that we cannot guarantee the order of execution as it depends on CI workload and workers availability.}