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
Usage:
USES=eigen:<version>[,<type>]
version: 2 or 3 (required)
type: build (default), run
For example:
USES=eigen:2,build,run
will add a BUILD- and RUN_DEPENDS on math/eigen2, and
USES=eigen:3
will add a BUILD_DEPENDS on math/eigen3.
* Convert the existing ports to use it
- biology/iqtree: remove run time dependency (seemed not to be needed)
- graphics/movit: remove run time dependency (seemed not to be needed)
- science/avogadro: add run time dependeny (installed cmake file requires it to be present)
Reviewed by: rakuco, mat
Differential Revision: https://reviews.freebsd.org/D13702
Ports using USE_PYTHON=distutils are now flavored. They will
automatically get flavors (py27, py34, py35, py36) depending on what
versions they support.
There is also a USE_PYTHON=flavors for ports that do not use distutils
but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if
using distutils but flavors are not wanted.
A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
added to cope with Python ports that did not have the Python
PKGNAMEPREFIX but are flavored.
USES=python now also exports a PY_FLAVOR variable that contains the
current python flavor. It can be used in dependency lines when the
port itself is not python flavored. For example, deskutils/calibre.
By default, all the flavors are generated. To only generate flavors
for the versions in PYTHON2_DEFAULT and PYTHON3_DEFAULT, define
BUILD_DEFAULT_PYTHON_FLAVORS in your make.conf.
In all the ports with Python dependencies, the *_DEPENDS entries MUST
end with the flavor so that the framework knows which to build/use.
This is done by appending '@${PY_FLAVOR}' after the origin (or
@${FLAVOR} if in a Python module with Python flavors, as the content
will be the same). For example:
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}
PR: 223071
Reviewed by: portmgr, python
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12464
If MAKEOBJDIRPREFIX and WRKDIRPREFIX are same PLIST may point to a
non-existing file under .OBJDIR without breaking build.
$ export MAKEOBJDIRPREFIX=/tmp
$ echo WRKDIRPREFIX=/tmp >>${__MAKE_CONF-/etc/make.conf}
$ cd /usr/ports/print/harfbuzz-icu
$ make clean patch
$ make -V .OBJDIR
/tmp/usr/ports/print/harfbuzz-icu
$ make install
$ pkg info -l harfbuzz-icu
harfbuzz-icu-1.5.1_2:
PR: 219008
Submitted by: Ilia Skalozubov (based on)
Approved by: portmgr blanket
src/CMakeFiles/gdl.dir/GDLInterpreter.cpp.o: In function `GDLInterpreter::l_decinc_dot_expr(ProgNode*, int)':
GDLInterpreter.cpp:(.text+0x4c24): undefined reference to `operator delete(void*, unsigned int)'
GDLInterpreter.cpp:(.text+0x4f51): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/GDLInterpreter.cpp.o: In function `GDLInterpreter::l_arrayexpr_mfcall_as_arrayexpr(ProgNode*, BaseGDL*)':
GDLInterpreter.cpp:(.text+0x51e9): undefined reference to `operator delete(void*, unsigned int)'
GDLInterpreter.cpp:(.text+0x5442): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/GDLInterpreter.cpp.o: In function `GDLInterpreter::l_arrayexpr_mfcall(ProgNode*, BaseGDL*)':
GDLInterpreter.cpp:(.text+0x5ab2): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/GDLInterpreter.cpp.o:GDLInterpreter.cpp:(.text._ZN5antlr15CharInputBufferD0Ev[_ZN5antlr15CharInputBufferD5Ev]+0x5d): more undefined references to `operator delete(void*, unsigned int)' follow
src/CMakeFiles/gdl.dir/basic_fun.cpp.o: In function `ForInfoListT<ForLoopInfoT, 32ull>::resize(unsigned long long)':
basic_fun.cpp:(.text._ZN12ForInfoListTI12ForLoopInfoTLy32EE6resizeEy[_ZN12ForInfoListTI12ForLoopInfoTLy32EE6resizeEy]+0x17e): undefined reference to `operator delete[](void*, unsigned int)'
src/CMakeFiles/gdl.dir/dcommon.cpp.o: In function `DCommon::~DCommon()':
dcommon.cpp:(.text+0xf5): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/dcommon.cpp.o: In function `DCommon::~DCommon()':
dcommon.cpp:(.text+0x154): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/dcommon.cpp.o: In function `DCommonRef::~DCommonRef()':
dcommon.cpp:(.text+0x3fd): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/dcommon.cpp.o: In function `DCommon::AddVar(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)':
dcommon.cpp:(.text+0x482): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/dcompiler.cpp.o: In function `DCompiler::ForwardFunction(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)':
dcompiler.cpp:(.text+0x226): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/dcompiler.cpp.o:dcompiler.cpp:(.text+0x314): more undefined references to `operator delete(void*, unsigned int)' follow
src/CMakeFiles/gdl.dir/envt.cpp.o: In function `ForInfoListT<ForLoopInfoT, 32ull>::~ForInfoListT()':
envt.cpp:(.text._ZN12ForInfoListTI12ForLoopInfoTLy32EED2Ev[_ZN12ForInfoListTI12ForLoopInfoTLy32EED5Ev]+0x76): undefined reference to `operator delete[](void*, unsigned int)'
src/CMakeFiles/gdl.dir/envt.cpp.o: In function `EnvUDT::~EnvUDT()':
envt.cpp:(.text._ZN6EnvUDTD2Ev[_ZN6EnvUDTD5Ev]+0xca): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/extrat.cpp.o: In function `ExtraT::ResolveExtra(EnvBaseT*)':
extrat.cpp:(.text+0x1aaa): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/fmtnode.cpp.o: In function `FMTNode::~FMTNode()':
fmtnode.cpp:(.text+0x44): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/gdlexception.cpp.o: In function `WarnAboutObsoleteRoutine(antlr::ASTRefCount<DNode>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)':
gdlexception.cpp:(.text+0x1c6f): undefined reference to `operator delete(void*, unsigned int)'
gdlexception.cpp:(.text+0x1eab): undefined reference to `operator delete(void*, unsigned int)'
src/CMakeFiles/gdl.dir/gdlxstream.cpp.o:gdlxstream.cpp:(.text._ZN10GDLXStreamD0Ev[_ZN10GDLXStreamD5Ev]+0x1d): more undefined references to `operator delete(void*, unsigned int)' follow
PR: 219300
Reported by: pkg-fallout
Submitted by: rakuco
(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
This release introduces some new features and fixes several bugs:
http://savannah.gnu.org/forum/forum.php?forum_id=8751
* update to 2.3 and take maintainership
* update math/py-gsl to 2.2.0 for gsl2 support
* update math/rubygem-rb-gsl to 2.1.0.2 for gsl2 support
PR: 218952
Exp-run by: antoine
Reviewed by: mat, rakuco
Approved by: rakuco (mentor)
Differential Revision: https://reviews.freebsd.org/D10522
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
The only reason to use post-stage is because the port needs to do
"things" at a later time, like some plist manipulation.
While there, fold post-install in do-install targets when they are
defined.
PR: 214780
Submitted by: mat
Exp-run by: antoine
Sponsored by: Absolight
GraphicsMagick was just updated, but there was as newer, second
PR to upgrade it once more. And again, the shared library version
has been bumped (haven't these guys heard of symbol versioning?)
While the INDEX references 114 users of GraphicksMagick, I'm going to
only bump the same 8 ports as yesterday. The bump script appears to
be obsolete (still uses CVS!)
PR: 203547
Submitted by: Walter Schwarzenfeld
All applications in the ports tree works correctly with unicode version of wxGTK
Newer version of wxGTK are unicode only (3.0+)
Note that now WX_UNICODE macro is noop
For example (${OSVERSION} >= 900000 && ${OSVERSION} < 900021) is always true,
as is (${OSVERSION} > 900002 || ${OSVERSION} < 900000 && ${OSVERSION} > 800107).
Regarding patches, when an EXTRA_PATCHES is no longer needed, I remove it, when
it is always needed, I renamed it, in one case, I merged two patches.
Differential Revision: https://reviews.freebsd.org/D2209
The 3.0 series is an incremental improvement over the previous 2.8 series
despite the major version number change. A list of important changes is
available at http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html
On the porting side
* The minimum FreeBSD release we have to support in the ports tree is now
recent enough that ports/168671 can finally be committed: instead of
building and using CMake's own copies of bzip2, curl, expat, libarchive,
liblzma and zlib, we use the versions in ports and/or the base system.
* CMake's documentation system has been changed and vastly improved at the
cost of now depending on Sphinx. We still generate only man pages, but can
start generating the HTML documentation in the future if desired.
* devel/cmake-gui now uses Qt5 instead of Qt4 and does not needlessly build
the ncurses UI that is installed by devel/cmake itself.
* CMake commit 3816cd2 fixes a longstanding issue in the detection of the
Python interpreter and its libraries, but requires us to revert a
workaround for that in Mk/Uses/python.mk itself, effectively reverting
the patch introduced by ports/168159.
* Similarly, a few ports had to be fixed manually due to CMake being
stricter when parsing some files or the ports detecting Python the wrong
way. Fortunately, they all had been fixed upstream so I just grabbed the
appropriate commits and pointed to them in the patches.
science/gnudatalanguage had to have its PORTREVISION bumped because
switching to USES=cmake:outsource removed a few files from the plist that
were not supposed to have been installed in the first place.
PR: 168671
PR: 192644
