some dummy packages must be only re-installable via ./configure --with-...

[dimpase]

$SAGE_LOCAL/bin/sage-env-config must get updated after, say, sage -i mpir (or any other dummy package that sets anything in the build environment). Currently this does not happen. This is a bug introduced in #27212 that leads to sage -i mpir breaking stuff.

To deal with this, we introduce a kind of dummy packages, freezable,
which differ from dummy so that they (once frozen) cannot be re-installed via
sage -i, but only via re-running ./configire --with-... first.

Specifically, for gmp and mpir, which are the only freezable packages so far, ./configure --with-mp=system freezes, them, and
./sage -i gmp or ./sage -i mpir errors out.
To unfreeze, one needs to do first ./configure --with-mp=gmp (or =mpir).

The branch implements this. If an attempt is made to run ./configure --with-mp=gmp, (or any other "frozen" package) while Sage is configured with external gmp, one gets the error message

***********************************************
 before running ./sage -i/f gmp please run
   ./configure <dollar sign>(./config.status --config) --with-mp=gmp
***********************************************

Depends on #27212

CC: @embray

Component: build

Reviewer: Dima Pasechnik

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

[dimpase]

comment:1

We can also merely document that ./sage -i blah must be run after ./configure --with-blah=install, perhaps also insert some warning print somewhere...

[dimpase]

comment:2

I looked a bit into how ./sage -i blah may trigger a run of ./configure --with-blah=install - this is not hard, assuming --with-blah is a parameter known to configure. E.g. it can grep for it in the output of ./configure -h, and
run, if found.

This will require having each package blah for which such a configure run is needed to implement the corresponding --with-blah=, (or, perhaps, something like
--install-blah, to make it even clearer)

---

An alternative might be to do this via special Makefile targets, something I am much less keen on.

[dimpase]

comment:3

On further reflection, it won't fly yet, as it would need to remember the exact parameters used to call ./configure...

An easier hack would be to set a flag in the call of sage -i blah which would be tested by the spkg-install of blah and if it's on, rewrite the corresponding part of
src/bin/sage-env-config. A relatively ugly hack, but looks relatively easy to implement.

[dimpase]

comment:4

Scratch all the above - it's simply the matter of having spkg-install to change src/bin/sage-env-config $SAGE_LOCAL/bin/sage-env-config.

Does this look right?

I suppose this fix should be added to #27212, not here...

[dimpase]

Description changed:

--- 
+++ 
@@ -2,5 +2,7 @@
 
 Possible fix:
 
- `sage -i blah` should run ./configure which (somehow) must ignore whatever one has in `blah/spkg-configure.m4`. E.g. `./configure` must get `--with-blah=` parameter which is by default `system`, but may be changed to `install` or `sage` or something like this.
+`blah/spkg-install` should overwrite the corresponding lines of `src/bin/sage-env-config`. 
 
+~~`sage -i blah` should run ./configure which (somehow) must ignore whatever one has in `blah/spkg-configure.m4`. E.g. `./configure` must get `--with-blah=` parameter which is by default `system`, but may be changed to `install` or `sage` or something like this.~~
+

[dimpase]

Description changed:

--- 
+++ 
@@ -1,8 +1,8 @@
-`src/bin/sage-env-config` must get updated after, say, `sage -i mpir` (or any other dummy package that sets anything in the build environment). Currently this does not happen. This is a bug introduced in #27212 that leads to `sage -i mpir` breaking stuff. 
+`$SAGE_LOCAL/bin/sage-env-config` must get updated after, say, `sage -i mpir` (or any other dummy package that sets anything in the build environment). Currently this does not happen. This is a bug introduced in #27212 that leads to `sage -i mpir` breaking stuff. 
 
 Possible fix:
 
-`blah/spkg-install` should overwrite the corresponding lines of `src/bin/sage-env-config`. 
+`blah/spkg-install` should overwrite the corresponding lines of `$SAGE_LOCAL/bin/sage-env-config`. 
 
 ~~`sage -i blah` should run ./configure which (somehow) must ignore whatever one has in `blah/spkg-configure.m4`. E.g. `./configure` must get `--with-blah=` parameter which is by default `system`, but may be changed to `install` or `sage` or something like this.~~
 

[kiwifb]

comment:6

Replying to @dimpase:

Scratch all the above - it's simply the matter of having spkg-install to change src/bin/sage-env-config.

Does this look right?

I suppose this fix should be added to #27212, not here...

If you change src/bin/sage-env-config, you'll have to re-install it. The one used at runtime is SAGE_LOCAL/bin/sage-env-config. The real way to do that is to have individual packages install the environment variable they need and then sage-env to read them. Like Erik suggested before. Such variables not being handled by the package themselves just lead to madness just as you are experiencing now.

[dimpase]

comment:7

right, I realised it must be $SAGE_LOCAL/bin/sage-env-config an hour ago, as you can see from the ticket description.

I don't get the second part of the comment - using a system package instead of Sage-supplied one might affect the environment, and the package responsible for this must take care of this, so that its "dependees" know about it. I don't see how sage-env is involved (besides that it uses sage-env-config).

[dimpase]

Author: Dima Pasechnik

[dimpase]

Commit: 8473658