Since quite some time, it's possible to download generated tarballs from
gitlab for a tag name without knowing the corresponding git hash. This
is preferable because you have a single source of truth about the
software version.
Support this by replacing GL_COMMIT with GL_TAGNAME which also accepts a
commit hash, similar to USE_GITHUB. Unfortunately, there's a catch, the
DISTFILE must be named exactly: ${GL_PROJECT}-${GL_TAGNAME}.tar.bz2,
otherwise it extracts in a directory that contains the commit hash. So,
we can't add the gitlab account or the revision suffix to make it work.
Therefore, detect whether GL_TAGNAME contains a commit hash, and if it
does, use the old behavior of deriving DISTNAME and DISTFILES.
Document in CHANGES, also add a DEV_WARNING similar to USE_GITHUB when
there's an URL in MASTER_SITES that looks like a gitlab URL. With
support for tags, there shouldn't be any reason left to hardcode such an
URL in MASTER_SITES.
PR: 248967
Approved by: portmgr (tcberner, mentor)
Differential Revision: https://reviews.freebsd.org/D37077
Run Tools/scripts/indent_make_if.pl on all of Mk.
These white space changes contribute greatly to the readability of those files.
As we have a version control system, finding out the reasons for the changes
prior to these white space changes is still easily possible
Differential Revision: https://reviews.freebsd.org/D35024
Reviewed by: portmgr (rene, bapt)
While here, modernize some comments in Mk/bsd.*.mk.
Note that graphics/drm-fbsd11.2-kmod is not renamed yet, this was somewhat
under discussion.
Submitted by: rene
Reviewed by: antoine, jbeich, mat, zeising
Differential Revision: https://reviews.freebsd.org/D21974
feature options define combo like auto/yes/no in a standand way.
In other words, upstream projects of ports that use _MESON_YES are
supposed to migrate to _MESON_ENABLED.
https://mesonbuild.com/Build-options.html#features
Reviewed by: tobik (implicit)
Approved by: portmgr (mat)
Differential Revision: https://reviews.freebsd.org/D19127
- People keep adding options named DEBUG to enable verbose things in
their ports and have no idea it also enables WITH_DEBUG.
- We already have WITH_DEBUG_PORTS that can enable WITH_DEBUG on a per
port basis.
Differential Revision: https://reviews.freebsd.org/D16829
variables deprecation revision
WITHOUT_NLS 2013-12-13 r336337
WITH_/WITHOUT_ 2014-02-24 r345870
NOPORT(DOC|EXAMPLE)S 2014-04-19 r351587
WITH_BDB_VER 2016-05-02 r414444
OVERRIDE_LINUX_BASE_PORT 2016-09-05 r421387
WITH_OPENSSL_(BASE|PORT) 2016-06-16 r416965
While there, add an ERROR variable that works like DEV_ERROR, but for
user facing errors, and move NOPORTDOCS,
NOPORTEXAMPLES and WITHOUT_NLS to it.
Cleanup bsd.sanity.mk a bit.
Fix fallout.
PR: 224613
Submitted by: mat
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D13490
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
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
For example a option of the "boolean" type only accepts true/false this
option is covered by ${opt}_MESON_TRUE/_FALSE.
Add option helpers ${opt}_MESON_YES/_NO for the "combo" type which
accepts yes and no.
Approved by: portmgr@ (mat@)
Differential Revision: https://reviews.freebsd.org/D11078
This uses will handling building software that uses the meson
build system. Expand the option framework to handle MESON options.
Approved by: portmgr (swills@)
Differential Revision: https://reviews.freebsd.org/D104091
This makes it possible to have:
opt_USE= ldconfig=${PREFIX}/lib/foo/bar
Before this, it would have ended up doing USE_LDCONFIG=/lib/foo/bar,
without ${PREFIX}.
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D8169
This fixes the devel/git-lite port to not get PERL despite being excluded.
PR: 207460
PR: 202701
With hat: portmgr
Differential Revision: https://reviews.freebsd.org/D5538
Until now, the only way to obtain information on the valid port options
and the current selection states is by using the pretty-print-config
target. It would look something like this:
> make -C /usr/ports/lang/gcc5-aux print-print-config
Standard[ +FORT +OBJC +NLS -TESTSUITE -ALLSTAGES -STATIC ] \
Bootstrap[ -BOOTSTRAP ]
To process the total options and the selection state of each option
requires additional processing, e.g. with awk and/or sed. Moreover, if
other information is needed about the port it question, it would require
a second execution of "make" to reveal variable values. There simply is
no other way to obtain the option selection information in a single pass
(this limitation came when options framework was brought in).
This enhancement allows the option selection information to revealed with
make -V so that all port information can be acquired in a single pass.
Moreover, they won't require piping through sed or awk. Two read-only
variables are introduced:
SELECTED_OPTIONS (list of all "on" options)
DESELECTED_OPTIONS (liss of all "off" options)
Here's an example of a single pass acquisition:
> make -C /usr/dports/lang/gcc5-aux -V PKGNAME -V SELECTED_OPTIONS \
-V DESELECTED_OPTIONS
gcc5-aux-20150716
NLS OBJC FORT
BOOTSTRAP STATIC ALLSTAGES TESTSUITE
Obviously the grouping information seen in pretty-print-config is lost,
so these new variables will not help if option group information is
required.
Approved by: portmgr (bapt)
TEST option is used when a port needs extra depends or flags for
build phase to enable tests (so TEST_DEPENDS don't work). Enable
it by default for DEVELOPER builds, so interested parties and Q/A
can have all tests available.
Approved by: portmgr (bapt)
Differential Revision: D3844
Due to the way .for loop work, opt_VARS was being expanded too early
evaluation, which made it impossible to use vars that are set/modifies
afterwards (such as PREFIX or PKGDIR)
Fix this by changing opt_VARS handling logic so that the right side is
not prematurely expanded:
- Loop not by words (each word here is single VAR=val / VAR+=val tuple)
but by unique left sides of assignments (VAR, VAR+ here)
- Using the left side, extract all corresponding right sides and
append/assign them to a variable
This changes the way this opt_VARS line work, which behavior is between
invalid and undefined:
opt_VARS= FOO=bar FOO=baz
Before it would end up with "FOO=baz", now it ends up with "FOO=bar baz"
Submitted by: amdmi3
Reviewed by: antoine, mat
Approved by: my portmgr hat
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D3729
You can now `make test' on any port to run test sequence, no-op by default.
If a port defines TEST_TARGET, it'll run sub-make with specified target,
usually `check' or `test', useful if upstream supports that. The port may
instead define custom do-test target, as well as usual satellite targets:
{pre,do,post}-test, {pre,do,post}-test-OPT, {pre,do,post}-test-OPT-off
`make test' builds and stages port first, so test may use both WRKDIR and
STAGEDIR, and both BUILD and RUN depends are available for test target.
Additionally, TEST_DEPENDS is now properly supported and may be used to
define additional depends specifically for testing.
Framework may define default tests for specific cases. For instance,
perl5.mk and cran.mk already provide default test target on their own.
This commit also converts my ports which have tests to this new framework.
Approved by: portmgr (bapt)
Differential Revision: D3680
OPT1_VARS= foo=bar baz+=bam
will set FOO to bar and append bam to BAZ if OPT1 is enabled. <opt>_VARS_OFF
works the same way, if the option is disabled.
Reviewed by: bapt
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D3410
