If we don't clean, then the upcoming make build won't notice any changes
that we actually added to the Makefile, such as setting the CONFIGURE_STYLE
to "modbuild tiny".
Noticed by Mischa <obsdml () high5 ! nl>
clean at the end of a build.
Add a new global config option: NEVER_CLEAN
so that no path ever gets cleaned (to be used ONLY if you have lots of disk
space).
I've actually done this manually in the past, to test various tools on
lots of objdirs...
These were previously used to automatically add tags to PLIST for
Haskell library ports. Since library ports no longer exist, such
tagging only ever triggers for ghc package where it is now harmful.
ok kili
While here try using @v/list first, if that fails use @latest. This should
fix some of the "not being able to see the latest version" issues that
happen when upstreams re-tag.
Tweaks / OK from afresh1
- 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