Before this, it could have been set to the current flavor of the port
that may not have been related to Python at all.
This of course never came up during development because at that time,
the only flavors were the Python flavors.
Reported by: dbn
Sponsored by: Absolight
The requested version of python can be set via USES=python:version
This change allows to build most ports depending on devel/py-gobject3
with DEFAULT_VERSIONS=python=3.x
In the future, one of py3gobject3 or pygobject3 could be deprecated.
Before, it would only create the default symlink if the Python version
was the default Python version. Change that to if the Python flavor is
the default flavor.
PR: 224242
Sponsored by: Absolight
The issue becomes apparent when trying to build lang/php72-extensions
with sodium checked.
PR: 223811
Submitted by: Daniel Ylitalo <daniel@blodan.se>
Approved by: ale
- Pass MAKEFLAGS down into do-depends properly.
- Remove redundant dependencies, run-depends and lib-depends, from
targets that already depend on earlier targets that depend on
the needed targets.
Reported by: emaste
With hat: portmgr
There's a flaw in FLAVOR selection logic which makes python FLAVOR
default to py27 even with DEFAULT_VERSIONS=python=3.6. Fix this and
generate FLAVOR based on PYTHON_DEFAULT, PYTHON2_DEFAULT, PYTHON3_DEFAULT
(in that order) similar to how it's done in other parts of python.mk.
This does not affect FLAVOR in default setup (py27 remains), but
if python default version is modified, it will now properly affect FLAVOR.
Approved by: portmgr (antoine)
Differential Revision: D13326
has changed, so it still should work as well (or not) as before, but it's
essentially untested and if anyone needs an older version from the GCC 4.x
era, 4.9 is still available.
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
To help with flavored ports, helpers are available. In these, replace <*>
with the flavor name.
*_PKGNAMEPREFIX *_PKGNAMESUFFIX *_PLIST *_DESCR will overwrite the variable.
*_CONFLICTS *_CONFLICTS_BUILD *_CONFLICTS_INSTALL *_PKG_DEPENDS
*_EXTRACT_DEPENDS *_PATCH_DEPENDS *_FETCH_DEPENDS *_BUILD_DEPENDS
*_LIB_DEPENDS *_RUN_DEPENDS *_TEST_DEPENDS will append to the variable.
Reviewed by: portmgr
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12483
- Enable FLAVORS.
- Make make describe flavors aware.
- Add a qa check for unique package names amongst flavors.
- Make MOVEDlint understand flavors.
- Add a bit of sanity check to make sure FLAVORS stay lowercase.
- Various fixes.
Reviewed by: portmgr
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12577
After r454995 build may fail if SSE2 is only enabled for C/C++ code as
simd crate expects SSE2 based on MACHINE_CPU.
PR: 223415 223300
Reported by: vvd@unislabs.com
This may help ports like textproc/ripgrep to run on old hardware.
Rust itself still requires SSE2 until bootstrap is regenerated.
PR: 223415
Approved by: rust (dumbbell)
- Rename USES=fortran:gcc to the more appropriate USES=fortran:gfortran.
- Change the options in math/R and math/libRmath so the choice becomes
flang or default instead of flang or gfortran. Use default Fortran
compiler again on amd64.
Some ports like graphics/povray-meta do funky things like add the same
option into PORT_OPTIONS twice. This also avoids a new leading blank
space in some cases.
With hat: portmgr
Notable changes:
- mcrypt module was removed
- sodium module was added
- sybase_ct artifacts removed
Also many PECL ports will not work with this version
since some files got renamed.
Reviewed by: mat, ale, Rainer Duffner <rainer@ultra-secure.de>
Differential Revision: https://reviews.freebsd.org/D12980
* update to 5.40.0
* unreleated cleanups:
- unify use of DISTVERSION
- remove created by line
PR: 223602
Exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D12966
If a port modifies OPTIONS_UNSET after including bsd.port.options.mk
then these values were wrong even though all of 'showconfig',
'pretty-print-config', and the package generated all had the expected
options.
Only Poudriere and synth use these variables for incremental build checks.
Reviewed by: sjg, bapt
Approved by: portmgr (bapt)
Differential Revision: https://reviews.freebsd.org/D13092
Not a MFH candidate due to POLA violation per redesigned UI, broken
legacy addons and auto-reviewed new addons.
Changes: https://www.mozilla.org/firefox/57.0/releasenotes/
PR: 222693
Tested by: pi, tobik, TrueOS
Currently, validation of JAVA_{VERSION,VENDOR,ERROR} does not constitute an
error and make(1) will happily continue, potentially doing the wrong thing.
Adjust the behavior as follows:
- Only validate each var if it's defined
- Remain verbose about what error exists and what's expected
- Fail the build if validation fails
bsd.java.mk exhibited this behavior up until r217132 inadvertently changed
it to be non-fatal.
PR: 220737
Approved by: portmgr (bdrewery)
* 222612: www/qt5-webkit: for armv6/v7: The cacheFlush support is missing on this platform
* 216816: devel/qt5: In arch.test, use CXXFLAGS from make environment
PR: 222612,216816, 223289
Exp-run by: antoine
Submitted by: mmel, mikael.urankar@gmail.com
Reported by: Mark Millard <markmi@dsl-only.net>, mmel
Reviewed by: mmel, mikael.urankar@gmail.com
Differential Revision: https://reviews.freebsd.org/D12816
They must be all uppercase, so that they do not conflict with flavors
that are lowercase.
Reviewed by: bapt
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12810
sip is installed as sip-${PYTHON_VER}
- py-qt*-demo: Fix packaging with python3, those ports have a python2 pkg-plist
so USE_PYTHON=py3kplist must be used to convert it
PR: 219641
USES=fuse:3 does add a dependency on version 3 of libfuse, which is not
compatible with version 2 (which remains default version for now). Both
versions can co-exist at build and run time.
Reviewed by: mat
Approved by: mat (portmgr)
Differential Revision: https://reviews.freebsd.org/D12694
flang is currently only available for amd64.
PR: 220313
Submitted by: yuri@rawbw.com
Reviewed by: db, jmd, mat, swills
Approved by: portmgr
Differential Revision: https://reviews.freebsd.org/D12529
old FreeBSD make (pmake) and there are no more users of it left in
the ports tree.
Differential Revision: https://reviews.freebsd.org/D12634
Approved by: portmgr (bapt)
Fix supported versions in USES=t[cl|k], remove last consumer (lang/fpc-tcl) and
bump PORTREVISION on two other ports that have had their dependencies or
default options changed (lang/smalltalk and x11-toolkits/ocaml-labltk)
Qt has been looking for its dependencies in PREFIX, rather than in
LOCALBASE. Dependencies are expected to exist in LOCALBASE, but
PREFIX may be set arbitrarily by the end-user. When PREFIX != LOCALBASE,
Qt-based ports failed to build.
PR: 222994
Reported by: kargl
Approved by: tcberner (kde)
Exp-run by: antoine
MFH: 2017Q4
Differential Revision: https://reviews.freebsd.org/D12666
The COPYTREE_BIN and COPYTREE_SHARE macros use constructs like
sh -c 'command' -- arg0 arg1
and assume that $0 will expand to arg0 and $1 will expand to arg1.
Our current sh implements it that way. However, POSIX specifies that $0 will
expand to -- and $1 will expand to arg0, since the command string is an
operand and not an option-argument. Bug #220587 requests making sh
POSIX-compliant in this regard.
If the argument after the command string does not start with '-', the
current sh behaves as required by POSIX. Therefore, adjust the macros so
this is always the case.
PR: 222870
Approved by: portmgr (antoine)
The flag has partial support across the tree, and the same effect
can be obtained by using ".undef WITH_DEBUG".
Reviewed by: mat, rene
Approved by: portmgr (rene)
Differential Revision: https://reviews.freebsd.org/D12548
cargo.mk is a little too eager in splitting a crate's name and version
in two when the version contains a dash (e.g. csv-1.0.0-beta.4) and
the wrong URL ends up being used in MASTER_SITES e.g.
.../csv-1.0.0/beta.4/download/...
instead of the correct one
.../csv/1.0.0-beta.4/download/...
Reviewed by: dumbbell
Differential Revision: https://reviews.freebsd.org/D12628
When defined it will create symlinks of some given binaries in a directory which
will be prepended to the PATH.
The syntax is the following:
BINARY_ALIAS= target1=source1 target2=source2
For example to have a "swig" binary in the path which will be pointing at
swig3.0 and a "sed" pointing at GNU sed: gsed
BINARY_ALIAS= swig=swig3.0 sed=gsed
Reviewed by: swills, adamw, mat
Approved by: swills (portmgr)
Differential Revision: https://reviews.freebsd.org/D12603
- linux- version cannot be updated due to lack of gtk3 package
- mirror -i18n distfiles locally until the langpacks are renamed
Changes: http://www.seamonkey-project.org/news
PR: 222464
Security: 5e0a038a-ca30-416d-a2f5-38cbf5e7df33
Security: 6cec1b0a-da15-467d-8691-1dea392d4c8d
Security: 555b244e-6b20-4546-851f-d8eb7d6c1ffa
Security: 1098a15b-b0f6-42b7-b5c7-8a8646e8be07
MFH: 2017Q4 (piling up until release)
part of USE_QT5, since all of those suggestions are wrong.
Approved by: rakuco (mentor), tcberner (mentor), portmgr (mat)
Differential Revision: https://reviews.freebsd.org/D12526
Having this enabled breaks Poudriere's ability to build py2 and py3 ports
together which FLAVORS aims to resolve. Once we have actual python
FLAVORS support ready to commit we can then enable this feature again.
With hat: portmgr
This is slightly early but due to recent PORTREVISION bump there's no
point doing QA for 55.0.* anymore.
Changes: https://www.mozilla.org/firefox/56.0/releasenotes/
PR: 221335
Security: 1098a15b-b0f6-42b7-b5c7-8a8646e8be07
MFH: 2017Q3 not possible: requires r447450 and r450556
**Do not start migrating any ports, a hook will prevent it**
This has been a long awaiting feature, most of the work has been done by
bapt, bdrewery and antoine, I am just the one actually doing the commit.
All this informations, and more to come are in the first link to our wiki
in the bottom block. A roadmap is in the second link.
To define a different flavors in a port, before any include, set:
FLAVORS= flavor1 flavor2 [...]
The first flavor in the list will be the default.
You can then check for flavors after includ'ing bsd.port.options.mk with:
.if ${FLAVOR} == flavor2
[some stuff]
.endif
To build flavor2, simply run:
make FLAVOR=flavor2
To depend on a specific flavor, write @<flavor> at the end of the depend
string, like:
RUN_DEPENDS= something:origin@foo
Submitted by: bapt, bdrewery, antoine
Reviewed by: portmgr
More infos: https://wiki.freebsd.org/Ports/FlavorsMigration
Todo List: https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
With hat: portmgr
Differential Revision: https://reviews.freebsd.org/D10327
* Once upon a time, we checked all of STAGEDIR/PREFIX's executable
files.
* We then decided too many false positives were found, so we switched to
only checking executable files in bin/sbin/libexec/www, and also
symlinks that were in there.
* And then, we decided to go back to check all of STAGEDIR/PREFIX's
executable files, but forgot to remove the checks for symlinks (which
are now useless because we already check all the executable files.)
Reported by: lifanov
Sponsored by: Absolight
Use `mysql_config --version` instead of `mysql --version` because
in MySQL 8.0 the format of output is changed and it'd be [more reliable] and
easier to use just mysql_config because it only returns the numbers we want.
Reviewed by: brnrd, mat (mentor, portmgr)
Approved by: brnrd, mat (mentor, portmgr)
Sponsored by: EuroBSDCon Paris Devsummit
Differential Revision: https://reviews.freebsd.org/D12458
Cargo started to ship with Rust in 1.19.0_2. I forgot to indicate the
port revision in the 1.19.0_2 commit.
Reported by: jbeich@
Differential Revision: https://reviews.freebsd.org/D12460
Failed builds can occur when PORTSDIR is a symbolic link, or with
make -C /usr/ports/category/port/
PR: 221296
Reported by: yasu@utahime.org, rum1cro@yandex.ru
Reviewed by: bdrewery, sjg
Approved by: portmgr (bdrewery)
Differential Revision: https://reviews.freebsd.org/D11934
This port now provides Cargo. This is the recommended now because Cargo
won't be provided separately in the future.
To build Cargo, we set `extended = true` in `config.toml`. As a side
effect, this flag also installs Rust source code. The port has a new
`SOURCES` option (disabled by default) to keep those sources.
As a consequence of this, `devel/cargo` is removed. Several ports
and Makefiles in Mk were updated to depend on `lang/rust` instead of
`devel/cargo`.
The other big change in this patch is the use of the bundled crates,
instead of relying on Cargo's registry (which was part of the distfiles,
in order to allow offline builds). So now, we don't need to prepare the
registry when updating this port.
This has several other benefits:
* It fixes the build with sudo(8).
* It fixes the use of the ino-64 patch (it was not applied to the
registry, thus not used).
Compilation errors were fixed in the ino-64 patch.
Various `.cargo-checksum.json` files are updated after the sources are
patched (FBSD10_FIX, ino-64, and so on). This fixes builds which were
failing with errors such as:
error: the listed checksum of `.../rustc-1.19.0-src/src/vendor/lzma-sys/xz-5.2.3/build-aux/config.rpath` has changed:
expected: c8b4c017079da9dfb3086a0583e60ffe736184d89005dc5973f0bb0fd17c04bb
actual: 561b00eb30ecaef2c9da17bc195e7d2a7ea63facea38ea9849fbb0ed340bebba
PR: 221088
Reported by: joneum@, nwhitehorn@, romain@,
Ekaterina Vaartis <vaartis@cock.li>,
david@catwhisker.org,
fullermd@over-yonder.net,
rum1cro@yandex.ru,
w.schwarzenfeld@utanet.at
Differential Revision: https://reviews.freebsd.org/D11783
When this was added by r392084 on 2015-07-14, the default flavor of GCC
was GCC 4.8 and explicitly requesting GCC 5 (or later) was necessary for
C++ 14 support. Now that the default version of GCC is GCC 6, after GCC 5
for several months, we can use the preferred notion of USE_GCC=yes instead
of specifying a concrete minimum version.
Among others this helps with cases where GCC 6 is better adjusted for
FreeBSD, notably the well known std::to_string issue (where that is only
enabled with GCC 6 or later).
PR: 222268
Approved by: portmgr (antoine)
MFH: 2017Q3
PR: 221816
Reviewed by: lifanov (mentor), matthew (mentor), mat
Approved by: lifanov (mentor), matthew (mentor), mat
Differential Revision: https://reviews.freebsd.org/D12125
By default the compiler will find /usr/bin/ld for the linker. If a port
sets LLD_UNSAFE and /usr/bin/ld is ld.lld, then add -fuse-ld=bfd to
force the use of the binutils BFD linker (from the base system, if
available, or by setting USE_BINUTILS).
This change is based on an earlier, similar patch from bapt, with the
addition of the -fuse-ld flag.
PR: 214864
Reviewed by: bapt
Approved by: portmgr (bapt)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D12064
Update the default Objective-C compiler.
Fix various build failures in GNUstep ports from newer versions of the GNUstep
core libraries and from changes to GNUstep Make.
Update various ports that use GNUstep and bump the portrevision of the ones
that haven't had a new release.
Upstream seems to define "default" as Nightly (custom build), not safe
to update automatically. Once we switched to proper channels updater
kicked in, except Mozilla never built binaries for FreeBSD. Not to
mention, vendor updates conflict with system package manager.
PR: 221541
MFH: 2017Q3
Qt WebEngine provides functionality for rendering regions of dynamic web
content. In other words, this is Chromium's Blink web engine and parts of
Chromium's content layer wrapped by Qt. Qt WebKit is deprecated upstream, and
WebEngine is the future.
This port has been in the works for a very long time, with contributions by
myself, tcberner, Adriaan de Groot and Marie Loise Nolden.
Since most of the port is just a large part of Chromium's code base, this means
sharing some of the pain www/chromium goes through by having to patch a ton of
files. We cannot share the exact same patches because this version of Qt
WebEngine is based on an older Chromium release.
I have verified that the port works, but it is possible that many things are
still wrong or missing, so bug reports are encouraged.
Reviewed by: Adriaan de Groot <groot@kde.org>, tcberner
Differential Revision: https://reviews.freebsd.org/D12063
Since r422306, we use a separate distinfo file for www/qt5-webkit because it is
no longer part of official Qt5 releases. However, we forgot to remove it from
QT_DIST in bsd.qt.mk, which means `make makesum' from other Qt5 ports was
trying to fetch qt5-webkit from the wrong location.
Reviewed by: tcberner
