Advantages of this modularization:
. much parallelization during the build
. no need to rebuild every module for each update
. define each license
. only the needed package may be installed
Also adding an option to disable the optimization.
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
After last update, compiler:openmpi comes before compiler:c++11-lang. This effectively overrides compiler:c++11-lang and causes base GCC to be used.
compiler:openmpi could probably be dropped, now that all supported FreeBSD versions have compiler that supports OpenMP (either GCC or Clang), but this would mean that Clang architectures would switch from GCC to Clang for this port, so it would have to be separately tested by the maintainer.
* Fix build on i386 [1]
* Fix science/code_saturne build with new openblas [2]
* Avoid installing private headers [3]
* Prevent build from optimizing for host by correcting build confg [4]
* Bump portrevision of dependent ports [5]
This is correcting issues from r523749 [1][2][4] and r515970 [3]
PR: 231371
Reported by: build cluster [1]
Reported by: Dima Pasechnik <dimpase+freebsd@gmail.com> [2]
Reported by: many [5]
Reviewed by: mat, bapt
Approved by: implicit, since this is a build fix
- Allow using Clang again (base libomp.so or OpenMP disabled)
- Respect C++ library if using GCC (must be libc++ on Clang architectures)
- Respect CFLAGS/CXXFLAGS in subdirectories using CMake
- Respect BLAS/LAPACK choice (actually use OpenBLAS)
- Enable Intel threading building blocks support
- Switch to vendor build/install targets
- Adjust plist for new items (GraphBLAS, Mongoose, DOCS)
- Skip running demos during build
PR: 240899
Tested by: pkubaj
Approved by: fortran (thierry)
MFH: 2019Q4
- Upgrade to 5.4.0 (Latest stable release) (2)
- Since I'm here make the pre-configure operations visible.
PR: 239080 (1)
Submitted by: imagin8r (T) protonmail.com
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
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
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
(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
lang/gcc which have moved from GCC 4.8.5 to GCC 4.9.4 (at least under some
circumstances such as versions of FreeBSD or platforms), part II.
The first part covered ports with USE_GCC=yes, USE_GCC=any, or one of
gcc-c++11-lib, openmp, nestedfct, c++11-lib as well as c++14-lang,
c++11-lang, c++0x, c11 requested via USES=compiler.
This adds ports with USES=fortran and ports using Mk/bsd.octave.mk
which in turn has USES=fortran.
PR: 214965
Reported by: thierry
