Put ${PATCH_WRSKRC} within quotes so that expanding it works properly when it
contains spaces. This is required for `make makepatch' to work with
audio/quimup or any other port that has WRKSRC with spaces. Before the patch:
% make -dl makepatch
cd: too many arguments
cd: too many arguments
and the port would be left with an empty files/ directory.
Reviewed by: marino
Approved by: portmgr (mat)
Differential Revision: https://reviews.freebsd.org/D5011
This is particularly useful if a port only needs to build a subdirectory of
the source tree (in which case they can set BUILD_WRKSRC to
"${CONFIGURE_WRKSRC}/foo/bar").
of octave segfaults with FreeBSD. Many of the octave-forge-* ports don't
build, and those that build don't work. So they are all being marked
broken until it is fixed.
LICENSE= PD
Note that although Public Domain is not technically a license, it's
handled in the same way as licenses here, which is a common practice
(Arch, Gentoo, Fedora, Debian, even FOSSology do the same).
Convert all ports which redefine Public Domain LICENSE to LICENSE=PD.
Approved by: portmgr (bapt)
Differential Revision: D4149
Now you can use, for example,
LICENSE= GPLv2+
instead of incorrect
LICENSE= GPLv2 GPLv3
or inaccurate and not machine readable
LICENSE= GPLv2 # or later
Also add some categorization to licenses list and fix some
whitespace problems in bsd.licenses.db.mk
Approved by: portmgr (bapt)
Differential Revision: D4148
The USES= fragments are not supposed to modify OPTIONS_* because they are
loaded after bsd.options.mk.
In the particular case of drupal, this resulted in SELECTED_OPTIONS and
DESELECTED_OPTIONS being incorrect. A second problem was that the "="
was used for assignment rather than "?=", meaning that any port with
USES=drupal got their options overwritten at some point (this included
the main www/drupal6 and www/drupal7 ports).
This commit adds OPTIONS_DEFINE=DOCS to almost every port that had set
USES=drupal to correct the mistake of setting options in Mk/Uses.
PR: 206060
sqlite and firebird handling code has been extracted from bsd.databases.mk
add an entry in bsd.sanity.mk to mark USE_SQLITE and USE_FIREBIRD as deprecated
"clang version 3.8.0 (trunk 256945) (based on LLVM 3.8.0svn)" was giving
"38 38" was a result. Now duplicates for fmake are trimmed and only the first
version found is used for bmake using its :tW.
With hat: portmgr
In collaboration with: dim
already had USES=pathfix, although it did nothing. For those ports, I
either removed it as they were handling the pkgconfig files differently
or I removed patches and substitutions that accomplished the same thing
as pathfix.
Differential Revision: https://reviews.freebsd.org/D850
Reviewed by: antoine, bapt, tijl
Approved by: portmgr (bapt)
- Do not silence installation message
- Use . instead of \* for COPYTREE_SHARE
- Use do-test:
- Use MAKE_CMD
- Remove validate:
- Cosmetic change
Differential Revision: https://reviews.FreeBSD.org/D4749
PR: 205774
Exp-run by: antoine
MFH: 2016Q1
This is similar to what we did for Qt4 in r362770. Some C++11 features actually
depend on the C++ standard library, such as <initializer_list> or std::move().
So far, ports with USES=compiler:c++0x and similar failed to build with Qt5 on
FreeBSD 9.x, as base libstdc++ is very old and does not support those C++11
features.
Piggyback on a check that is already present upstream for OS X, which has the
same ancient libstdc++ version. Apple's version has a custom patch with version
macros that we can't use, so we make a broader check and disable the features
that depend on a modern standard library if libc++ is not used.
Some ports may need to use Python for their testing suite but otherwise
do not need it at all (ie, not for build or run). This patch adds
support for the test argument to be used in the USES clause, such as
python:3.2+,test. This enables the relevant Python environment and
modifies TEST_DEPENDS as necessary.
For non-Python ports that use Python as their testing suite, add
python:<ver>,test as required to the USES clause.
PR: 205616
Submitted by: Brendan Molloy <brendan+freebsd bbqsrc net>
Reviewed by: mat, miwi, koobs, antoine
Approved by: koobs (python)
Differential Revision: https://reviews.freebsd.org/D4711
There are some inefficiencies in python.mk that significantly slow down
full tree scanning. The use of bmake to obtain the current version of
a specific python is responsible for the majority of the slow done.
This commit splits out the PYTHON_PORTVERSION definition (which is the
same as the lang/python* PORTVERSION) into separate files. With this
change, python.mk can simple include the makefile fragment instead of
spawning a new instance of make.
Different Revision: https://reviews.freebsd.org/D4660
Approved by: antoine (python), mva (python)
This is another shot at fixing the linkage problems that have plagued our
users particularly when upgrading from Qt 5.x to 5.(x+1). Quick recap: in
Qt5, qmake will by default pass QMAKE_LIBDIR to the linker before other
directories such as ${WRKSRC}/lib, which is where the port's libraries are
built. When a user is upgrading Qt, we can end up with the following linker
line:
c++ -o SomeBinary -lfoo1 -L/usr/local/lib -L${WRKSRC}/lib -lfoo2 -lfoo3
If libfoo2.so is being built by the port and an older version is currently
installed on the system, /usr/local/lib/libfoo2.so will be picked up instead
of the newly-built ${WRKSRC}/lib/libfoo2.so. At best things just work, at
worst SomeBinary needs some new symbol that is not present in the old
libfoo2.so and linking fails. Case in point: bug 198720.
The previous approach, adopted when fixing bug 194088, was to stop setting
QMAKE_{INC,LIB}DIR in the FreeBSD mkspecs and set the CPATH and LIBRARY_PATH
environment variables in Uses/qmake.mk. This way we just did not pass
-L/usr/local/lib to the linker at all and things mostly worked. However,
people using Qt to build their own software without the ports tree were out
of luck, as they would then need need to deal with passing
/usr/local/{include,lib} to the compiler/linker themselves (bug 195105). Not
only that, but if a dependency mentioned /usr/local/lib we would still have
problems anyway (in bug 198720, the GStreamer pkg-config files contain
-L/usr/local/lib, for example).
We now solve the issue by setting the QMAKE_LIBDIR_FLAGS variable in
.qmake.cache to ${WRKSRC}/lib instead. qmake appends the value of
QMAKE_LIBDIR to QMAKE_LIBDIR_FLAGS, so we are always sure -L${WRKSRC}/lib
will come before -L/usr/local/lib in the linker options. Moreover, qmake is
smart enough to automatically call sed(1) and remove references to
${WRKSRC}/lib from .prl and .pc files when installing them.
PR: 194088
PR: 195105
PR: 198720
MFH: 2015Q4
This is the latest Calligra release, and the 2.9 series will be the last
KDE4-based release series.
As usual, huge thanks to Tobias Berner <tcberner@gmail.com> for working on this
in kde@'s area51 experimental repository (including previous Calligra releases
between 2.7.5 and 2.9.10).
Notable changes from a packaging perspective:
- Several dependencies have been updated to use more recent ports versions.
- Old translations not shipped by the current Calligra release have been
removed.
- The dependency on sysutils/nepomuk-core has been dropped, following what
upstream has done.
- The dependency on Qt3-compatibility Qt4 ports has been dropped, following
upstream.
- CONFLICTS with ancient ports have been removed.
- Support for G'MIC (GREYC's Magic for Image Computing), introduced after
2.7.5, is disabled by default, as building the code with clang requires
insane (>24GB) amounts of memory. We reported this bug to the LLVM developers
(bug 22199) almost a year ago, but there has been no activity upstream.
- Stopped depending on graphics/pstoedit in an unorthodox way: just follow what
every major Linux distribution does and unconditionally depend on it. I could
not figure out why we were originally depending on the port if it was already
installed.
- Stop playing tricks with PACKAGE_BUILDING: we do not package Vc
(https://github.com/VcDevel/Vc) so it does not make sense to turn on support
for it when building packages. Not only that, but the CMake option name was
wrong (it should be PACKAGERS_BUILD, not WITH_PACKAGERS_BUILD).
