Bug 246887 - catch Mk/Uses/fortran.mk up to bsd.gcc.mk r301973
Summary: catch Mk/Uses/fortran.mk up to bsd.gcc.mk r301973
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Mark Linimon
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-31 03:54 UTC by Mark Linimon
Modified: 2020-06-03 21:15 UTC (History)
5 users (show)

See Also:


Attachments
patch to Mk/Uses/fortran.mk (792 bytes, patch)
2020-05-31 03:54 UTC, Mark Linimon
no flags Details | Diff
patch to Mk/Uses/fortran.mk (789 bytes, patch)
2020-06-01 01:34 UTC, Mark Linimon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Linimon freebsd_committer freebsd_triage 2020-05-31 03:54:23 UTC
Created attachment 215087 [details]
patch to Mk/Uses/fortran.mk

In order to test 246700, fortran.mk needs to catch up to changes long-ago made to bsd.gcc.mk.

The general problem is that bsd.gcc.mk cannot handle the idea of "gccX-devel", as bsd.gcc.mk was taught to.

This is the first part of a multipart patch.  They need to be carefully examined.  However, this part should be merely a refactoring.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2020-06-01 01:34:36 UTC
Created attachment 215118 [details]
patch to Mk/Uses/fortran.mk

Replacement for first patch
Comment 2 Tijl Coosemans freebsd_committer 2020-06-01 15:21:44 UTC
_GCC_RUNTIME is missing "gcc", it should be "${LOCALBASE}/lib/gcc${_GCC_VER}".  I'm also thinking we should prefix private variables with _FORTRAN or something so they are less likely to interfere with bsd.gcc.mk.
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2020-06-03 10:22:22 UTC
(In reply to Tijl Coosemans from comment #2)
> _GCC_RUNTIME is missing "gcc", it should be "${LOCALBASE}/lib/gcc${_GCC_VER}".

Then you get the string "gccgcc".  That's why I changed it from the first way I had it.

> I'm also thinking we should prefix private variables with _FORTRAN or something so they are less likely to interfere with bsd.gcc.mk.

My current view is that the case of USE_GCC=<anything> and USES+=fortran does not even work now.

Both of my patches need more work.
Comment 4 Tijl Coosemans freebsd_committer 2020-06-03 10:57:55 UTC
(In reply to Mark Linimon from comment #3)
> Then you get the string "gccgcc".

Hmm, I don't see how that's possible.  _GCC_VER is derived from GCC_DEFAULT, which should only contain the version number.  Where does it pick up "gcc"?
Comment 5 Tijl Coosemans freebsd_committer 2020-06-03 12:59:22 UTC
(In reply to Mark Linimon from comment #3)
> My current view is that the case of USE_GCC=<anything> and USES+=fortran does not even work now.

That is somewhat intentional.  We want all Fortran ports to be compiled with the same compiler and that implies the same USE_GCC.  Not doing so is asking for trouble with runtime libraries.  If a port needs a newer version it should set IGNORE directing the user to modify his DEFAULT_VERSIONS.  If it's stuck on an older version it should probably set BROKEN with a similar message.

If I were the maintainer of bsd.gcc.mk I would do the same there.  It's simpler to maintain.  It makes it more likely that users have only one version of gcc installed and therefore have fewer problems with runtime libraries which means there are fewer support questions to deal with.  And marking old ports BROKEN allows us to get rid of them faster, or it might incentivise their maintainers to fix them with newer gcc faster.

Anyway, what I'm trying to say is, please don't introduce any of the bsd.gcc.mk "magic" in fortran.mk.  Making it possible to choose "10-devel" as gcc default would be nice though.
Comment 6 Gerald Pfeifer freebsd_committer 2020-06-03 21:15:37 UTC
(In reply to Tijl Coosemans from comment #5)
> We want all Fortran ports to be compiled with the same compiler and that 
> implies the same USE_GCC.  Not doing so is asking for trouble with runtime
> libraries.  If a port needs a newer version it should set IGNORE directing
> the user to modify his DEFAULT_VERSIONS.  If it's stuck on an older version
> it should probably set BROKEN with a similar message.
>
> If I were the maintainer of bsd.gcc.mk I would do the same there.

I have been moving into that direction over time (pushing hard to
minimize exceptions to USE_GCC=yes or USE_GCC=any) and streamlining
the logic further earlier this year.

At this point for nearly all users GCC_DEFAULT is the only one they
should ever encounter. Which is the same that USES=fortran implies.

Exceptions are two-fold:

 1. Systems with the 13-year old GCC 4.2 in base.

 2. A short list of exceptions.

    GCC 4.8.
    sysutils/memtest86+
    sysutils/uefi-edk2-bhyve - in contact with maintainer
    GCC 7.
    devel/xtensa-esp32-elf - in contact with maintainer
    GCC 9.
    devel/dwarves
    graphics/rawtherapee
    lang/gcc10
    lang/spidermonkey60


Item 1 above would be easy to address. Simply remove the block starting with
  .if ${USE_GCC} == any && exists(/usr/bin/gcc)
from Mk/bsd.gcc.mk. If have proposed this, but Mark did not like it.

> It's simpler to maintain.  It makes it more likely that users have only
> one version of gcc installed and therefore have fewer problems with
> runtime libraries which means there are fewer support questions to 
> deal with.  And marking old ports BROKEN allows us to get rid of them
> faster, or it might incentivise their maintainers to fix them with newer
> gcc faster.

Amen. Plus users on all platforms/systems would use the same version of
GCC, which is not the case for the 54 ports with USE_GCC=any right now
when /usr/bin/gcc is present.

> Anyway, what I'm trying to say is, please don't introduce any of the
> bsd.gcc.mk "magic" in fortran.mk.  Making it possible to choose "10-devel"
> as gcc default would be nice though.

Agreed. And if you look at the evolution of bsd.gcc.mk you'll find that
I managed to trim the amount of "magic" (and code) significantly.
USE_GCC=any is the biggest offender right now. Beyond that I cannot
actually think of much more in terms of simplifications.