build/pkgs/gfortran/spkg-configure.m4 works incorrectly if CC and CXX are already there

[dimpase]

As a result of refactoring configure.ac in #24919,
absence of (g)fortran now forces installation of full gcc, instead of just gfortran part of it.

This is particularly crucial on OSX, where we don't normally build full gcc any more, but only build gfortran.

To reproduce, move gfortran out of your PATH, and re-run ./configure. You'll see that now gcc and gfortran are scheduled for installation...

CC: @embray @jhpalmieri @vbraun @kiwifb

Component: build: configure

Author: François Bissey

Branch: 3185e91

Reviewer: Erik Bray

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

[dimpase]

Description changed:

--- 
+++ 
@@ -1,6 +1,8 @@
-As a result of refactoring configure.ac in #24919, it appears that
+As a result of refactoring configure.ac in #24919,
 absence of (g)fortran now forces installation of full gcc, instead of just gfortran part of it.
 
 This is particularly crucial on OSX, where we don't normally build full gcc any more, but only build gfortran.
 
+To reproduce, move gfortran out of your PATH, and re-run ./configure. You'll see that now `gcc` and `gfortran` are scheduled for installation...
 
+

[dimpase]

comment:2

It appears that all what's needed is

--- a/build/pkgs/gfortran/spkg-configure.m4
+++ b/build/pkgs/gfortran/spkg-configure.m4
@@ -14,7 +14,6 @@ SAGE_SPKG_CONFIGURE([gfortran], [
         # compiler.
         if test -z "$FC"; then
             sage_spkg_install_gfortran=yes
-            SAGE_MUST_INSTALL_GCC([a Fortran compiler is missing])
         fi
 
         # see http://www.gnu.org/software/hello/manual/autoconf/Fortran-Compiler.html

with this change, and no gfortran in PATH, everything looks as it should after running ./configure.

Could someone with access to OSX please try this? (Don't forget to run ./bootstrap before
./configure, i.e. you do need autotools for such a check...).

[kiwifb]

comment:3

This is all a bit tricky. What control logic is there when you don't have gfortran (so that the above check will say sage_spkg_install_gfortran=yes) but gcc must be installed as well?

[dimpase]

comment:4

Replying to @kiwifb:

This is all a bit tricky. What control logic is there when you don't have gfortran (so that the above check will say sage_spkg_install_gfortran=yes) but gcc must be installed as well?

There is build/pkgs/gcc/spkg-configure.m4 which should take care of this.

[kiwifb]

comment:5

Replying to @dimpase:

Replying to @kiwifb:

This is all a bit tricky. What control logic is there when you don't have gfortran (so that the above check will say sage_spkg_install_gfortran=yes) but gcc must be installed as well?

There is build/pkgs/gcc/spkg-configure.m4 which should take care of this.

It doesn't but the the section of code you point too in the diff can only be reached if sage_spkg_install_gcc is no. Otherwise the variable I was worried about is set to no.

The only real issue to be careful here is that the gcc bit needs to be run before the gfortran bit. If we go by lexical order everything is fine in this particular case. But that may be something to remember if there is ever another package with an "optional split" or a where checking a dependency first is important.

[dimpase]

comment:6

It seems to be the case for "package Bar provides functionality Foo" kind of stuff that one can dive in :-P

Should this Sage component be called YAPS (Yet Another Packaging System)? And by virtue of name it must be implemented in yaml...

[kiwifb]

comment:7

Amusing. But more seriously your diff certainly point to an issue that needs to be fixed and is logically what we are after. However the line probably should be replaced with a notice. It was probably the intent in the first place. When do you intend to submit a branch for review?

[embray]

comment:9

Replying to @kiwifb:

Amusing. But more seriously your diff certainly point to an issue that needs to be fixed and is logically what we are after. However the line probably should be replaced with a notice. It was probably the intent in the first place. When do you intend to submit a branch for review?

I think having some kind of notice was the intent, though written exactly as I did was probably a mistake on my part. Looking at the diff from #24919, this is the original code I removed from configure.ac:

-# Check that the Fortran compiler accepts free-format source code
-# (as opposed to the older fixed-format style from Fortran 77).
-# This helps verify the compiler works too, so if some idiot
-# sets FC to /usr/bin/ls, we will at least know it's
-# not a working Fortran compiler.
-AC_LANG(Fortran)
-if test -z "$FC"; then
-    need_to_install_gfortran=yes
-else

and this is the equivalent code that was moved to build/pkgs/gfortran/spkg-configure.m4:

+        # Check that the Fortran compiler accepts free-format source code (as
+        # opposed to the older fixed-format style from Fortran 77).
+        # This helps verify the compiler works too, so if some idiot sets FC to
+        # /usr/bin/ls, we will at least know it's not a working Fortran
+        # compiler.
+        if test -z "$FC"; then
+            sage_spkg_install_gfortran=yes
+            SAGE_MUST_INSTALL_GCC([a Fortran compiler is missing])
+        fi

The use of the SAGE_MUST_INSTALL_GCC macro here is a mistake. It might be a remnant from before we created a separate "gfortran" package (that actually happened after I first introduced #24919, and while I tried to incorporate that change it looks like this might have been left in).

As Dima suggested it can just be removed and/or replaced with an AC_MSG_NOTICE.

[embray]

comment:10

Actually, I think there needs to be a bit more logic restructuring too. That fi should be an else. There's no point in checking AC_FC_FREEFORM if $FC is empty, as in the original code.

[dimpase]

comment:11

I'd say we're wedded to gfortran too much. As far as I know, flang is in a good state, and a good candidate to replace gfortran (well, yes, it's not that fast yet, but, OK...).

This ticket would be a good occasion to fix this, and check for presence of a meaningful Fortran compiler, not specifically gfortran.

[embray]

comment:12

This really isn't specifically about gfortran. It is, in fact, just checking that a fortran compiler exists, and if not is installing gfortran. Let's not overcomplicate things here: We've identified a simple fix. I'll attach a patch if no one else does.