Bug 246887
| Summary: | catch Mk/Uses/fortran.mk up to bsd.gcc.mk r301973 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Mark Linimon <linimon> | ||||||
| Component: | Ports Framework | Assignee: | Port Management Team <portmgr> | ||||||
| Status: | New --- | ||||||||
| Severity: | Affects Only Me | CC: | fortran, gerald, rene, rhurlin, thierry, tijl | ||||||
| Priority: | --- | ||||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
Created attachment 215118 [details]
patch to Mk/Uses/fortran.mk
Replacement for first patch
_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.
(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. (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"? (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. (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. reset PR |
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.