Release notes: <https://github.com/openexr/openexr/releases/tag/v2.3.0>
Adjust LIB_DEPENDS of all ports that require ilmbase or openexr to chase
the new lower-case spelling of the name, and to omit the version from the
library name to ease future maintenance.
Bump PORTREVISION of all ports that depend on ilmbase or openexr directly,
so that they all get rebuilt on upgrades.
Add patches to graphics/ampasCTL to keep it alive, with (a) ilmbase now
that its Iex::BaseExc class is no longer derived from std::string,
details were given upstream through https://github.com/ampas/CTL/issues/71
and (b) to unwind semicolon/;-lists in cmake that stem from openexr/
ilmbase pkg-config variables.
(Note ampasCTL is unmaintained as FreeBSD port, and upstream,
and I cannot run-time test it.)
Poudriere build tests on 11.2-RELEASE-p1 amd64 of ALL ports depending
directly or indirectly on ilmbase and/or openexr have passed without
regressions. Thus invoking due diligence, I believe I have done the
equivalent of an -exp run, and do not require approval for the dependency
chases to third-party ports.
in the ports tree (via Mk/bsd.default-versions.mk and lang/gcc) which
has now moved from GCC 6 to GCC 7 by default.
This includes ports
- featuring USE_GCC=yes or USE_GCC=any,
- featuring USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and those
- with USES=compiler specifying one of openmp, nestedfct, c11, c++0x,
c++11-lib, c++11-lang, c++14-lang, c++17-lang, or gcc-c++11-lib.
PR: 222542
- Utilize PLIST_FILES instead of pkg-plist to avoid passing ${PORTVERSION}
and ${PORTVERSION:R} via PLIST_SUB (not very elegant, but quite clear)
Found out via: repology.org [*]
Because GitHub releases (tarballs) are not fetched with correct modification
time, set TIMESTAMP to 1507854327 which corresponds to commit aefa609 tagged
as this release.
(via Mk/bsd.default-versions.mk and lang/gcc) which has moved from
GCC 5.4 to GCC 6.4 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++11-lang,
c++14-lang, c++0x, c11, or gcc-c++11-lib.
PR: 219275
lang/gcc which have moved from GCC 4.9.4 to GCC 5.4 (at least under some
circumstances such as versions of FreeBSD or platforms).
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using using Mk/bsd.octave.mk which in turn has USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++14-lang,
c++11-lang, c++0x, c11, or gcc-c++11-lib.
PR: 216707
- Make HDF5 support (and thus the dependency) optional
- USE_GL and Boost dependencies are no longer needed, remove them and
their associated patch files
- Remove CMAKE_ARGS: it was setting values which are the defaults now
- Add missing USE_LDCONFIG and move USE_GITHUB together with other USE_*
knobs: while it makes sense to have a dedicated GitHub-related block
of knobs, single USE_GITHUB does not really warrant it
- Remove HDF5_ROOT gimmick for Alembic < 1.6.0's AlembicHDF5.cmake as it
is no longer required (ditto for the patch)
Reported by: portscout [*]
Because GitHub releases (tarballs) are not fetched with correct modification
time, set TIMESTAMP to 1490314701 which corresponds to commit 895a7c6 tagged
as this release.
CMake's FindHDF5.cmake underwent some refactoring upstream and it now respects
the HDF5_ROOT variable in more places and separates HDF5_LIBRARIES from
HDF5_HL_LIBRARIES.
Do some slight adjustments to the Alembic port for it to continue working with
the upcoming CMake 3.6.1 (they are no-ops with CMake 3.5.2 which is currently
in the ports tree):
- Set HDF5_ROOT via CMAKE_ARGS so that Alembic does not set it to a nonsensical
value.
- Add HDF5_HL_LIBRARIES to ALEMBIC_HDF5_LIBS so that libhdf5_hl.so continues to
be passed to the linker.
PR: 210988
function with corresponding __atomic_* counterpart and link with libatomic
against GCC. This should be no-op on Tier-1 architectures (against Clang),
since that code branch is guarded by __GNUC__ >= 4 && __GNUC_MINOR__ >= 4.
