is a new target "show-all" that fits to the existing "debug",
"show-tools", "show-vars" targets. It prints a list of the variables
that make up the public interface to pkgsrc. Running this target is
especially useful if you want to do some things, you know that they must
have been implemented but you don't know what it is called. It also
shows the "class" of a variable (user-defined, package-defined,
system-defined).
"gdk-pixbuf/Makefile.in" from the "gtk2" package as "libtool library file".
Change the textfile check to accept any file which file(1) identifies
as "<whatever>libtool<whateverelse>" to fix the build of the
"gtk2" package (and probably other packages).
PKG_FAIL_REASON in that case. It didn't have an effect anyway for normal
builds, since subst.mk is included after checking PKG_FAIL_REASON.
Discussed with jlam.
evaluated. Now the SUBST_MESSAGE is only printed once when the
substitution is actually done. Before this change it had been printed
also when the subst-<class> target had been invoked a second time, but
the substitution didn't take place again, which had confused me. Also,
converted the code to use ${WARNING_MSG} and ${STEP_MSG}.
SUBST_MESSAGE is printed. The ones that have been defined with "quotes"
in their Makefiles are printed with quotes (of course). This is the
consequence of the design pattern "quote-exactly-where-necessary", which
in fact should be have been applied to pkgsrc as a whole, but still isn't.
detection whether a given file was a text file or some other file had
been unreliable. In the recent bulk builds, all of the warnings that had
appeared because of that unreliable detection had been false positives.
variables that use the :sh modifier. This still causes expansion to only
happen when referenced, and has the advantage of being :Q-safe.
Bring back the changes from revision 1.19 of mk/subst.mk now that the
problem noted above has been fixed. This passes the buildlink-unwrap
regression test.
assumptions being made by the USE_PKGLOCALEDIR code and the wrapper
framework since it added backtick expressions to the SUBST_FILES.*
variables, which were being mangled by the :Q modifier. This is
evident when running "make regress" in regress/buildlink-unwrap.
Mea culpa.
"foo" as "foo.subst.sav". Implement SUBST_POSTCMD, which by default
cleans up these leftovers. If you need to keep them around, e.g.
while debugging, set it to ${DO_NADA}.
Remove superfluous whitespace in a comment.
unintentionally.
Also revert revision 1.6 as part of the overall change, as I suspect
the change might be unnecessary. While I'm not 100% sure, this does
just revert to the previous behaviour.
before subst'ing it.
previously, only a warning would be printed and the .subst_done
cookie(s) would be created, indicating that the subst target was
successful when it really was not.
output of file(1) which reports too many false negatives (not
detecting a file as a text file when it really is).
package developers are aware of which files the subst operation
applies to, since they need to specify the filenames, so this test is
not really required.
it's also not inconceivable that one would want to subst over a
non-text file, which is now possible.
pipeline that takes stdin, performs the substitions and writes the result
to stdout. It defaults to ${SED} ${SUBST_SED.<class>}. Use this variable
to replace the sed command with something else, like an awk process.
facility for different classes of files in ${WRKSRC}. For each class of
files, a target <class>-subst is created to perform the text replacement.
The following variables are used:
SUBST_STAGE.<class>
"stage" at which we do the text replacement, e.g. pre-configure,
post-build, etc.
SUBST_MESSAGE.<class>
message to display, noting what is being substituted
SUBST_FILES.<class>
files on which to run the substitution; these are relative to
${WRKSRC}
SUBST_SED.<class>
sed(1) substitution expression to run on the specified files
This basically extracts a useful piece of code from bsd.buildlink2.mk and
puts it in a place that allows it to be more widely used, and so that the
functionality doesn't depend on USE_BUILDLINK2 being defined.