Re: Concensus on PKGSRC_FORTRAN?=gfortran?

[Greg Troxel <gdt%lexort.com@localhost>]

John Klos <john%ziaspace.com@localhost> writes:

> Should we consider making PKGSRC_FORTRAN?=gfortran the default for
> bulk builds? Why or why not?

[I know some of this is redundant with offlist conversations.]

I don't think bulk builds should be different from regular builds,
barring some special reasons.

My impression is that while ~everyone thinks g95 is ~crufty, many also
think that making PKGSRC_FORTRAN default to gfortran was not clearly
safe yet in large part to it defaulting to gcc 4.8 always.

Now it's intended to default to matching the base system gcc version,
it seems like the right choice for most OS/VERSION/CPU tuples.
(However, due to a make-code bug, it picks gcc7 on NetBSD 8 -- but
that's actually ok I think -- separate note to follow.)

Currently, mk/compiler/gcc.mk picks gfortran on aarch64, and g95
otherwise.  clang.mk does the same thing.  This is recent, and AIUI
because g95 doens't work on aarch64 -- so gfortran has to be equal or
better.

So the big questions are:

  Is this decision just about CPU type, or also about OS, or further
  about OS version?

  Are there any platforms where it is truly desired to use g95 instead
  of gfortran?

  Is this something to change during the freeze?  (We usually don't do
  things like this.)


I think the first two questions are a bit up in the air.   So while I
don't like us to have persistent long-term differences from bulk builds
and defaults, I think it's just as well if anyone doing a bulk build
wants to set PKGSRC_FORTRAN=gfortran, and see how it goes.

FWIW I have been running with PKGSRC_FORTRAN=gfortran on NetBSD and
macOS for a long time.  I have not noticed problems due to this.


Perhaps we can just flip the default post-branch and deal with any
lossage, perhaps by os/version/cpu tuple flip back to g95, perhaps by
fixing it.