On 2023/01/16 11:46, Dima Pasechnik wrote: > On Mon, Jan 16, 2023 at 09:12:26AM +0100, Antoine Jacoutot wrote: > > On Sun, Jan 15, 2023 at 11:12:44PM +0100, Frederic Cambus wrote: > > > > > > When I imported binutils back in August, sthen@ hinted that it was a > > > bit strange to now have gas in a separate port [1], to which I agreed. > > > > > > Following the binutils 2.40 update, I enabled the build of gas in the > > > binutils package. This means we can now remove devel/gas. > > > > > > CC'ed MAINTAINER (pascal@) > > > > > > Comments? OK to remove it? > > > > math/py-numpy will need some love as it depends on devel/gas. > > Why should it even need gas? numpy needs clang+egfortran, and
IIRC, newer versions of gcc compilers emit asm code (at least on some architectures) which cannot be handled by the ancient as 2.17 in base. And some architectures don't have as in base at all. > BLAS/LAPACK. I normally build it with OpenBLAS (which in turn can > be built with clang+egfortran) - not the admittedly lame reference > BLAS/LAPACK. OpenBLAS is not packaged, sadly - although it's basically > the only option for performant free BLAS/LAPACK with a BSD license > nowadays. Such a setup allows building scipy on OpenBSD, by the way. The issue with OpenBLAS is that some things will pick it up in preference to BLAS/LAPACK and it's going to need someone with an interest in keeping the whole ports tree working (including on various architectures) to do the work to cope. Just providing it as a library in ports without doing the rest of the integration work causes more problems than it solves. > PS. some time ago I asked whether egfortran can be renamed (back?) to > gfortran, It is possible (it's been done for Ada) but a bit awkward because --program-transform-name applies to all of gcc's binaries. Also requires checking for other ports that will be affected by the different name and patching if necessary, or bumping REVISION if the binaries change if the compiler filename is embedded. > and its package should also be named gfortran, and not g95 (which is simply > wrong, as g95 is > a different, and dead by now, project). > (there is no gfortran package present any more, so it should be OK to re-use > the name) Also possible but a bit awkward, requires renaming via devel/quirks and @pkgpath markers and bumping revision for any ports which have a run dependency on that subpackage. Both the sort of thing where, if the maintainer agrees and someone has done the work (including making sure they don't break the wider ports tree) and a developer has time to do the necessary tests then it might be able to go in, but I doubt there are ports devs with enough spare time and interest in those non-critical changes to do all the steps.
