We no longer require that LIBTOOL_LA_FILES be defined in the package
Makefile, and the libtool archives should once again be listed in the
PLIST.
* Add a new yes/no variable "LIBTOOLIZE_PLIST" to control whether to
have bsd.pkg.mk automatically expand *.la files in PLISTs into the
true library names represented by the libtool archives.
* Rename the "transform-la" script to "print-la-libnames" which more
correctly reflects its function.
Many thanks to Todd Vierling for the original implementation and for
his contructive comments on how to improve the changes in this commit.
all of the .a, .la, .so, and .so.* files in the PLIST. This will
autogenerate the PLIST entries based on the informaion in the .la file.
This include print-PLIST support; if LIBTOOL_LA_FILES contains an
installed .la, its entries will be elided from the output PLIST template.
no listed homepage. Thanks to Grant Beattie for noting this and providing a
patch which I changed slightly.
- fix a bug which put extra stuff in the categories field. Thanks to Grant
for noting this.
several orders of magnitude and 'make index' now takes 30 minutes or so
instead of several days on my test machine. The approach now is to take
one pass through every package and extract some key information including
the explicitly listed dependencies. After the data is extracted, the
dependencies are flattened in one step which avoids the extremely
inefficient recursive make that was previously used.
- fix a bug in which caused only packages listed as DEPENDS to show
up in the 'packages needed to build' section. Now the BUILD_DEPENDS
are also shown. Thanks to Christian Hattemer for noting this.
- fix a bug which caused error messages claiming that category and top
level README.html files could not be created even though they were
created. This bug only showed up if an old README.html file did not
exist. As part of this, clean up and unify the code which handles
comparing the new README.html file to a possibly pre-existing one and
only copying it over if there is a change.
can be used anytime one needs to extract the complete dependency information
for a package for example, when creating a README.html file for the pkg.
The approach used by mkdatabase requires exactly one make call per package
which makes it scale well to packages with large dependency trees that have
many paths to the leaves.