pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mk.conf error from pkg_chk (Was: openjdk21 build errors)



To summarize, pkg_chk tries to determine PKGSRCDIR from running
essentially "make -f mk.conf -v PKGSRCDIR=${PKGSRCDIR} -v
LOCALBASE=${LOCALBASE}".

Am 28.01.2025 um 23:35 schrieb David Brownlee:
> I'm very much open to suggestions as to how to improve matters.
> Obvious options include
>
> [...]
>
> Give up on trying to autodetect pkgsrc location
> - I'd prefer not to lose that ability :)

In what kind of situation would you need this autodetection?

The point of pkg_chk is to keep a pkgsrc source tree in sync with a
pkgsrc binary installation.  In this situation, there should always be
only a single pkgsrc source tree, otherwise you can quickly get confused
about what package to build from which tree.

Once you have pkgsrc source and pkgsrc binary set up, chances are low
that one of them moves to a different location.  And even if that's what
happens, you can simply rebuild pkg_check to update the PKGSRCDIR that
would be hardcoded in the pkg_chk binary.

For example, lintpkgsrc also hardcodes PKGSRCDIR during the build, plus
a good guess for LINTPKGSRC_MAKECONF. The latter has been hardcoded
since 2022, and I didn't receive any complaints about it.

Before 2015, pkglint also hardcoded PKGSRCDIR, but since it is obvious
from each pkglint invocation what to check and look for a nearby
../mk/bsd.pkg.mk, newer pkglint doesn't need this hardcoded variable
anymore.

Am I missing some point here why hardcoding PKGSRCDIR would be bad?

Roland



Home | Main Index | Thread Index | Old Index