everything so that people updating from subsequent snapshots won't
have old clang 8-compiled packages lying around.
also will work around the problem where packages don't have WANTLIB
in sync, in some cases these have an unlisted dependency on libc++
which won't have been updated as needed (found by matthieu@).
ok ajacoutot@
we rerun pkglocate
also check the pkglocate cookie vs the fake cookie, so that we rerun things
if somehow fake was rerun without cleaning things first (unlikely, but still)
- De-duplicate our .mod and .zip files.
- Move chdir to a child process.
- Break MODGO_MODULES and MODGO_MODFILES values into their own lines
for easier reading.
Updating bigger ports with lots of patches, combing the target's output
for failed hunks can be cumbersome; print failed patch files one per line
iff there are any to provide immediate feedback on what wrong and where.
"definitely wanted" landry
Style nits, OK espie
using MODGO_MODNAME.
This is needed to work around this issue:
https://github.com/golang/go/issues/27455
which makes `make clean` because of the restrictive permissions.
input and corrections from sthen@ and jca@
ok sthen@ jca@ espie@
UPDATE_COOKIES and BULK_COOKIES are not generated by dpb, but if you
build stuff manually and use dpb, they can happen, and you will see error
messages in dpb logs (trying to remove them as _pbuild), so give them
to _pbuild/tweak fix-extract-permissions accordingly.
Also fix an old feature where you can force UPDATE_COOKIES into WRKDIR
which got broken a long time ago.
Thanks to solene@ for tests
there's a bug elsewhere (autovivification of $w->{info}{BUILD_PACKAGES})
that I need to track down that results in $w->{info} being defined but
NOT a proper object.
dpb errors out at end-of-LISTING in case of a parse error in any Makefile.
solene@ ran into this a few days ago, probably some other people, and
finally I met the bug today. Ouchie. sorry about that.
tweak the path for copy-debug-info so we don't accidentally neuter
THAT strip as well.
this helps getting cmake/qmake do the right thing without needing to
alter strip behavior.
rather than 'RUN_DEPENDS=${BUILD_DEPENDS}' which is easily polluted by
compression utilities, ccache if used etc. Problem spotted by aja@ in a
port submission of mine where the skeleton was made by portgen.
While there, prefer setting 'TEST_DEPENDS=${RUN_DEPENDS}' rather than
to '${BUILD_DEPENDS}' if RDEP/BDEP are equal.
ok afresh1@
With this a port can be easily generated for Go applications that support Go
modules (there will be a go.mod file in the root of the project).
For example: https://github.com/jrick/domain/blob/master/go.mod
The mod file lists "github.com/jrick/domain" as the module name, so a portgen
command to build the above tool would be:
portgen go github.com/jrick/domain
OK afresh1@ kmos@
PyPI projects that already list multiple supported Python versions cause
portgen(1) to generate a flavoured port; of leaving FLAVOR emtpy, opt for
the highest available version.
This makes it use FLAVOR?=python3 insteaf of FLAVOR?= (empty) if any
sypport higher than Python 2 is listed.
Note that PyPI projects listing either only one sypported version or none
at all are not effected by this diff.
OK afresh1 kmos
Alexei dot Malinin at mail dot ru reported a compiler warning that,
in my opinion, probably indicates a security vulnerability, but due
to an incomplete description of the affected feature in the
documentation, it is unclear how it should be fixed. The program
appears to be sloppily written, sloppily documented, and abandoned
upstream 15 years ago.
OK ajacoutot@ for deleting it.
Although I couldn't find a definitive guide to version specs,
I did find an example showing this seems to be how RubyGems work.
From Thomas L. <tom.longshine () web ! de>
out of existence: arch-defines.mk MUST be included very early on, so that
modules can use it to decide on behavior, BUT modules are allowed to set
DEBUG_PACKAGES without worrying about it, and so bsd.port.arch.mk must be
the place that zaps!
Discovered by sthen@, because xfce4.port.mk would start churning out
DEBUG_PACKAGES on every architecture.
tested by naddy@ because I wasn't sure I didn't miss something non obvious.
They do result in a bulk package build taking about a third longer, but
the bulk build machines are significantly faster than the machines most
people are running the produced packages on, so it's a trade-off: a bit
of pain for builders vs a lot of pain for users wanting to debug things
on their normal hardware.
