- 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.
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.
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
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>
for now it rescans "stubbed" ports in case you did change them (or if
they were stubbed because of missing dependencies, etc)
Could become something else/more powerful eventually
add a debug command (cores) that shows explicitly each core known by
the core system, including idle cores (available) and "behind the scene"
stuff (ssh masters)
specifically, make sure dpb can't get confused if the same fullpkgname
points to two different locks (by stubbing/erroring out)
Clean up the code a bit so it shows up in equiv.log and as broken (so in
engine.log)
bsd.port.mk bits to test later (and document because this has lots of
caveats and should only be used under specific circumstances)
I used to have "site" always set, but it takes space for broken files,
so I removed it, and it breaks in case distfiles are incomplete.
So, just make it possible for some things to go missing, and properly test
for them later.
Noticed by jca@
- add a parameter "full" so that we don't show version mismatches twice
- remove host name from information, since the order is the same as the header
line.
- beautify by doing a line feed after banner and indent by two spaces so it
tends to fit on the line
not-so-good change to just using the PortsQ "cache":
- use _paths/_ports directly rather than the "ports" view and remove bogus
flavour-clearing regex subst
- open sqlports ReadOnly
- ignore debug files in the fake directory
- recognize and annotate shared objects and static libraries correctly
*THIS REQUIRES CURRENT PKG_* CODE TO WORK!*
if your package contains static libraries/shared objects, update-plist
WILL error out saying it can't create the new classes
- contrary to merge_depends, build_distinfo can actually work one path
at a time.
- have DISTFILES be an ordered list to give more info to roach (first
distfile)
- so put build1roach in the middle of build1info so that the ordered
list is still available.
To be leveraged once I finish roach...
get closed automatically
for init core, if tasks did fail, do not continue.
in particular, this avoids calling DPB::Var->get on a failed host.
thx sthen@ for noticing this
