Just in case any of these tools defines some command line arguments. The
correct path had already been used before since both env and sh are added
to USE_TOOLS in bsd.pkg.mk.
A commonly occuring scenario is that a package patches the configure
script, but that the corresponding configure.in contains shell code that
is not portable. In cases like these, configure.in is typically not used
during the build, therefore there is no need to check it for portability.
This also applies to all other combinations where a file is patched and
the corresponding file.in contains unportable shell code.
When all files are skipped, the tool dependency is not added as well.
This allows packages to skip the check without defining the user-settable
variable CHECK_PERMS.
Since the portability checks are concerned about bashisms, it doesn't make
sense to apply them to programs that will later be run in bash anyway.
Suggested by gdt via private mail.
Since pkgtools/check-portability is not installed by default, it will not
harm any existing pkgsrc setup. To activate it, it has to be installed
manually. After a testing phase, it will be installed whenever
PKG_DEVELOPER is set.
can't be disabled by setting it to "no" like the other variables.
Besides, flavor/pkg/metadata.mk has been expecting for a long time that "no"
is a valid value.
Make PKG_DEVELOPER DWIM.
huge performance problem: When reading files, it calls read(2) for every
single byte. awk instead reads a whole line at a time. For the lang/php5
package, the execution time changed from (7.8 real 4.5 user 3.1 sys) to
(1.6 real 1.5 user 0.4 sys).
since according to the comment in check/bsd.check.mk, they belong there.
Added a new check for all C and C++ header files to make sure they don't
contain strings like ${prefix} or ${exec_prefix}, which is currently a
problem with sysutils/dbus and has been noticed in PR 35019. This check
is disabled by default since I don't know anything about possible false
positives, but I plan to enable it for PKG_DEVELOPERs after some
testing.
Added two names for hooks that are placed in the configure and in the
build phase. Now the checks look more like becoming something one could
call a framework, sharing a common structure and a documented interface.
2006-11-09 02:53:15 +00:00
Renamed from mk/configure/check-portability.mk (Browse further)
