./configure --without-system-A --without-system-B can build both A and B

[mkoeppe]

Some functionality can be provided by
either one of two SPKGs.

For such pairs (A, B) of SPKGs, configuring with

./configure --without-system-A --without-system-B

or equivalently

./configure --with-system-A=no --with-system-B=no

can result in both A and B being built.

Some cases are solved after the removal
of one of the spkgs in the pair.

• gmp vs mpir: remove mpir Remove package mpir #32549, complete mpir deletion #32727
• atlas vs openblas; remove atlas Remove ATLAS #30350
• full boost vs boost_cropped; remove full Remove full boost package #31575;
  m4 files use cropped replace boost by boost_cropped in m4 files #31871

Remaining cases:

• gfortran can be provided by the gcc or gfortran SPKGs
• some database packages have SPKG vs SPKG_small pairs

gfortran

Both gcc and gfortran built after

./configure --with-system-gcc=no --with-system-gfortran=no`

• sage-devel report

SPKG_small

  --with-system-pari_seadata={no|yes (default)|force (exit with an error if no usable version is found)}
                          detect and use an existing system pari_seadata
  --with-system-pari_seadata_small={no|yes (default)|force (exit with an error if no usable version is found)}
                          detect and use an existing system pari_seadata_small

Overall, we need a better solution for such pairs of packages.

CC: @orlitzky @dimpase @jhpalmieri @slel

Component: build: configure

Keywords: spkg-pairs

Issue created by migration from https://trac.sagemath.org/ticket/29620

[dimpase]

comment:1

perhaps fixing this in ./configure is the most natural thing to do.

[mkoeppe]

comment:2

I agree

[orlitzky]

comment:3

This is ugly because sage_spkg_install_mpir=no can mean multiple things when you take --with-mp into consideration. There's a simpler statement of the problem: passing --without-system-gmp causes the gmp SPKG to be installed when mpir will be used anyway. I haven't been able to wrap my head around a solution that works in all cases. We may need to introduce another variable that indicates what's actually going on, rather than trying to reverse engineer what happened from the sage_spkg_install variables at the end of gmp's post-check phase.

[mkoeppe]

comment:4

Yes, we should first define the meaning of these options.

[mkoeppe]

comment:9

Just got bitten by this again.

[orlitzky]

comment:10

We recently switched the default back to GMP because MPIR is bit-rotting. Being able to choose GMP instead of MPIR had obvious benefits when MPIR was the default. But is there any benefit to being able to use MPIR as an alternative when GMP is the default?

[mkoeppe]

comment:11

The only reason that comes to mind is that at least one package uses an mpir-specific interface: #30325.

For Sage 9.3, I would be reluctant to remove MPIR completely. But it would be good to remove this trap in our configure script.

[mkoeppe]

comment:13

For boost, of course, we could just remove the full boost package and only offer our cropped version of boost. It could be argued again that it's not Sage's job to provide a full boost installation. (Our version is ancient in any case)

[dimpase]

comment:14

removing full boost is certainly a good idea.

[mkoeppe]

comment:15

Replying to @dimpase:

removing full boost is certainly a good idea.

That's now #31575.

[mkoeppe]

comment:18

Moving to 9.4, as 9.3 has been released.

[mkoeppe]

comment:20

I have opened #32549 to remove package mpir

[slel]

Changed keywords from none to spkg-pairs

[slel]

comment:23

Reworded ticket description (removing some bits
reproduced below) after

• ATLAS removed in Remove ATLAS #30350.
• MPIR removed in Remove package mpir #32549 and complete mpir deletion #32727.
• work on boost and boost-cropped:
  • replace boost by boost_cropped in m4 files #31871: replace boost by boost_cropped in m4 files
  • Remove full boost package #31575: Remove full boost package
  • Upgrade: boost_cropped 1.78.0 #31250: Upgrade: boost_cropped 1.78.0

---

For gmp/mpir, we have:

  --with-system-gmp={no|yes (default)|force (exit with an error if no usable version is found)}
                          detect and use an existing system gmp
  --with-system-mpir={no|yes (default)|force (exit with an error if no usable version is found)}
                          detect and use an existing system mpir
  --with-mp=system        use the system GMP as multiprecision library, if
                          possible (default)
  --with-mp=mpir          use the Sage SPKG for MPIR as multiprecision library
  --with-mp=gmp           use the Sage SPKG for GMP as multiprecision library

The first two are automatically generated and do not work properly. The --with-mp option is legacy and works properly but does not fit well with the systematic naming scheme. Removing mpir in #32549 removes this case.

Same for BLAS (as reported most recently in https://groups.google.com/g/sage-support/c/pqnhfUJYS-Q/m/lOQJ3EtYBwAJ):

  --with-system-atlas={no|yes (default)|force (exit with an error if no usable version is found)}
                          detect and use an existing system atlas
  --with-system-openblas={no|yes (default)|force (exit with an error if no usable version is found)}
                          detect and use an existing system openblas
  --with-blas=openblas    use OpenBLAS as BLAS library (default)
    --with-blas=atlas       use ATLAS as BLAS library

Removing atlas in #30350 removes this case.

And to a lesser degree for these ones:

  --with-system-boost={no|yes (default)|force (exit with an error if no usable version is found)}
                          detect and use an existing system boost
  --with-system-boost_cropped={no|yes (default)|force (exit with an error if no usable version is found)}
                          detect and use an existing system boost_cropped