Update the CONFLICTS definitions of ports in the following categories:
- accessibility
- archivers
- audio
- benchmarks
- biology
- cad
- chinese
- comms
- converters
An attempt has been made to use generic conflicts patterns that do not
have to be updated whenever a new version of a conflicting port is
added to the ports system.
There is a misunderstanding that the port being built/installed has to
be omitted from the conflicts pattern. This is not true - the port
being built is implicitly non-conflicting due to logic in bsd.port.mk.
Approved by: portmgr (implicit)
- switches opencascade to vtk9 to enable upcoming import of
cad/py-ocp
- cad/freecad has to switch vtk8 -> vtk9, too
- this requires upstream commit 0cfea3fee3e7848bbf043d2b1a19f6405d7ebe25
"Make smesh compile with vtk9"
- while touching this, fixes vtk module detection
- clean up VTK_DIR usage: that variable does not exist in FreeCAD's
build system anymore (for quite some time, actually)
Obtained from: opencascade upstream: Kirill Gavrilov
Obtained from: freecad upstream: committed by github/wwmayer
Differential Revision: D30934
Reported by: thierry@
Submitted by: thierry@
Per discussion with bapt on helping pkg handle the changing of these
deps and avoiding impossible upgrade senarios.
PR: 246767
Reviewed by: manu, bapt
Approved by: x11
Differential Revision: https://reviews.freebsd.org/D30824
Intel oneAPI tbb 2021.1 (onetbb) has been released[1][2] and has deprecated
several interfaces over tbb 2020, breaking most dependent ports.
Old tbb 2020 will be kept for a certain time to allow transition but will be
removed in a near future as it CONFLICTS with devel/onetbb. New ports should
now use devel/onetbb instead of devel/tbb.
We tried to move a maximum number of dependent ports to devel/onetbb (or
disable dependency when not possible), but some of them still remain stuck
to devel/tbb. Remaining ones have not been identified as major dependencies
themselves and will be fixed as soon as updates are available from upstream.
PR: 252648, 252688 [3], 252683 [4], 252651 [5], 252690 [3], 252693 [3],
252695 [3], 252696 [3], 252786 [3], 252649, 252868 [6], 252870 [5],
252684 [7], 252785 [7]
Approved by: yuri [3], jwb [4], thierry [5], FreeBSD@Shaneware.biz [6],
maintainer timeout [7]
[1] https://software.intel.com/content/www/us/en/develop/articles/intel-oneapi-threading-building-blocks-release-notes.html
[2] https://software.intel.com/content/www/us/en/develop/articles/tbb-revamp.html
Since I´m there, add 3 more doc files to plist, but do not bump PORTREVISION to
avoid a rebuild.
PR: 253085
Submitted by: greg (at) unrelenting.technology
as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
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, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
Given no feedback to the contrary do the most sensible thing and
merge the two VIS_CMAKE_ON together.
PR: 234700
Approved by: thierry (maintainer timeout, 2 weeks)
Ports that build out of source now simply can use "USES=cmake"
instead of "USES=cmake:outsource". Ports that fail to build
out of source now need to specify "USES=cmake:insource".
I tried to only set insource where explictely needed.
PR: 232038
Exp-run by: antoine
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 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, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
(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
Using ninja instead of make (1) can lead to significant speed ups while building.
Therefore switch from having the ninja generator opt-in to having it opt-out.
Previously cmake-ports that wanted to use ninja could set
CMAKE_NINJA=yes
now, ports that do not work with ninja can set
cmake:<existing args>,noninja
Note, that needing this should be an exception and most often points to a broken
cmake of the port.
The ports using cmake were modified
* removed USES=gmake, if ninja is used
* removed MAKE_ARGS, if ninja is used
* added the cmake-argument noninja if necessary
PR: 219629
PR: 213331
Exp-run by: antoine
Reviewed by: rakuco
Differential Revision: https://reviews.freebsd.org/D10748
