This adds a set of Visual Studio NMake Makefiles that can be used to
build libpsl, either as a DLL or as a static .lib. Building of the psl
tool and the tests in tests/ (but not fuzz, since those tests use
fmemopen(), that is not supported on Windows) are also supported.
A simplified "install" target is provided that copies the build
results to a default or set prefix with the pkg-config file so that
other packages (such as libsoup) with build systems that depend on this
.pc file can be built.
These files make use of autotools stuff so that they have the up-to-date
version info upon a release.
Currently, only builds using the ICU runtime/builtin or with no
runtime/builtin are supported with Visual Studio builds.
Also add a new ./configure function to set a distribution wide
PSL file used by psl_latest(): --with-psl-distfile
If possible that filename should point to a DAFSA PSL file that
becomes updated regularly.
I've talked to the good people on #debian-bootstrap who would be most
affected by the possible build-dep cycle, and i think the simplest
approach is actually to split out make_dafsa.py into its own
architecture-independent package.
I'm thinking i'll call the package psl-make-dafsa, and in the course of
shipping it, i'll place src/make_dafsa.py as /usr/bin/psl-make-dafsa.
This is because:
* debian discourages scripts on the $PATH from having language-specific
suffixes like .py:
https://lintian.debian.org/tags/script-with-language-extension.html
* "-" appears to be a more common delimiter in command names than "_":
0 dkg@alice:~$ for x in - _; do printf "%s: %d " "$x" $(ls -1 ${PATH//:/ } | grep -c "$x"); done; echo
-: 1235 _: 368
0 dkg@alice:~$
* i'd prefer to prefix the command with "psl-" since it really is
producing and interpreting PSL-specific data structures.
Accepting this patch would mean i'd have fewer changes to make in the
debian packaging, and would allow other distributors to take a similar
approach if they want to.