On Nov 24, 2007, at 5:08 PM, Michael G Schwern wrote:
The "external" as its own key with a non-scalar
value should satisfy this as well.
$ perl Makefile.PL
Warning: prerequisite external HASH(0x1801180) not found.
That doesn't look very "satisfying" to me. Not to mention, it
doesn't show the user anything about what they need to know in order
to fix the problem.
I don't agree that we need a second tier of categorization. Why is
perl in
sys and not bin? Why is mysql in ext? Why is openssl not in lib?
I probably should have laid out the criteria for 'ext' vs. 'bin' vs.
'lib' vs. 'sys' in that previous message, but it seemed like it was
already getting too long. Here's how I imagine it:
* sys: facts about the system environment we're currently running
in, such as the version of perl, OS type & version, whether threading
is enabled, etc.
* bin: executable programs to be found in the PATH
* lib: libraries we can link to via XS
* ext: external systems we can interface to through other means
(sockets, daemons, protocols involving multiple interfaces, etc.)
With that in mind, here's how I justify those examples - but keep in
mind that things could indeed fall under more than one type,
depending on what's intended by the author. For example, 'bin/mysql'
would mean we need an executable like /usr/bin/mysql, while 'ext/
mysql' would mean an available socket connection to a running mysql
environment.
In general most people will want 'sys/perl' rather than 'bin/perl',
because the former means the currently-running Perl environment,
whereas the latter means a 'perl' executable can be found somewhere
in the path. That may not be true if we're in an embedded
environment, theoretically.
Similarly for the 'ext/openssl' example, I was intending to show a
dependency on a complete OpenSSL environment, including the openssl
command-line tool, the c_rehash tool, etc.; indeed I would agree most
SSL-related modules would prefer 'lib/ssl' to 'ext/openssl', but it's
up to the author.
These are questions we don't need to answer if we split everything
up into "perl
modules" and "everything else".
Not sure whether the proper response is:
1) We don't need to answer them here either, the author needs to
decide which alternative they intend.
or
2) Of course we would, if we wanted "everything else" to do
anything sensible.
But I'm confident it's one or the other. ;-)
The only reason I can think of for categorizing them is to attempt
to have
some sort of unified mechanism for dependency resolution. As there
is no
unified way to determine the version number, or even if its
installed, of
"everything else" there's really no reason to try to categorize them.
For a given platform, there are indeed unifying ways of searching the
PATH, or detecting/interrogating libraries, or gleaning system
information. Obviously that's not the whole task in determining
whether a prereq is satisfied, but it's a start.
I have in mind some mechanism that would by default do some
reasonable minimal check for 'bin' and 'lib' and some 'sys' items,
and allow the author to extend that check for actual semantic
verification. For instance, the author could tell us what flags to
pass to a 'bin' item to get version info out of it, and how to parse
the response to see if the dependency's met.
Perhaps some of this checking could be best handled by interfacing
with the Alien tools. I'm not sure though, I haven't kept up with
Alien, but my sense is that Alien might be a bit too loosely spec'ed
to serve the purpose we'd need.
-Ken
