On Mon, Feb 07, 2022 at 06:02:08PM +0000, [email protected] wrote:
> > Here is the diff I am currently testing on sparc64/arm64. More tests
> > welcome,
> > even on amd64.
>
> On -current, amd64, this is building fine + passing all "gmake check" and
> "gmake check-install" tests.
>
> I've also rebuilt math/netcdf (all tests but 1 are PASSED, if CC=egcc is
> added
> in TEST_ENV .. otherwise it is trying to use gcc). I haven't had the time
> to investigate yet the only failing test.
Seems odd. netcdf is all base-clang on amd64. How are you invoking tests?
'make test' in the ports dir is the prefered invocation. The test target
can be modified/improved with 'do-test' in the Makefile.
>
> I also have a port of the CGNS lib using hdf5 (not yet in ports, I'm just
> waiting for the hdf5 1.12.1 update before posting it on ML). All tests
> are also passed (for both hdf5 versions 1.12.0 or 1.12.1).
>
> >
> > VFD support is disabled, I don't know why the mirror server is built. It
> > does
> > not work with VFD disabled so I prefer not to package it.
>
> Makes sense.
>
> >
> > In OpenBSD, egfortran is gfortran from g95. But handling the compiler
> > link is
> > not standardized.
>
> Ok. I was just wondering if there was still a good reason to keep
> MODFORTRAN_COMPILER = {gfortran, flang} instead of {egfortran, flang}
> or if it was just a "reliquat" of the old times.
Not sure. There is not a lot of manpower available focussing on Fortran in
ports. It's a different topic to look into. Maybe someone else can comment.
>
> > I've also shuffled MASTER_SITES so that it works with portroach. HDF
> > still
> > points to 1.10.5 as current release.
>
> That, I didn't notice! Shouldn't it be removed then?
I'm not happy with putting part of the release number in MASTER_SITES,
but unless upstream fixes this we can just keep it.
