Dear David,
Thanks for the pointer to App::Info - it looks interesting. DBD::Informix already has to do a lot of stuff like that - and has classes which supports its efforts. Integrating that into a App::Info framework probably isn't too hard.
Question for you - not immediately clear from the docs. If I decide I want to use App::Info in Makefile.PL (or Build.PL) for DBD::Informix, do I have to put App::Info::RDBMS::Informix onto CPAN and persuade people to download it to their machine and install it - and App::Info too - or is there a way to ship App::Info::RDBMS::Informix and supporting code with DBD::Informix? The DBD::Informix Makefile.PL is already using ExtUtils::AutoInstall so it is far from impossible to augment the list of auto-installed software with App::Info and App::Info::RDBMS::Informix if that's appropriate, but it would be nicer if it was unnecessary. I suspect I could achieve the roughly equivalent effect by including lib/App/Info.pm and relatives in my lib directory - is that a plausible assumption and reasonable way to ensure that App::Info is available even on system without App::Info installed?
Which comes first, the chicken or the egg?
Also, I note that there are methods such as bin_dir, lib_dir, and so on. Is there (yet) a method that would return the 'base_dir' or 'home_dir' of an application? For example, Informix is located via the $INFORMIXDIR environment variable; then bin_dir is $INFORMIXDIR/bin and so on. I believe Oracle is similarly located via $ORA_HOME or something similar. Would it be plausible to add application-specific methods too - for example, App::Info::RDBMS::Informix::INFORMIXSERVER to determine the name of the default server, and A::I::R::I::INFORMIXSQLHOSTS to locate the sqlhosts file, etc? Finally, for now, what would you expect me to do to support different sub-products within the Informix collection? For sake of discussion, there are three servers, IDS, XPS, and SE, and the client libraries to access these, CSDK. Are these all RDBMS category? Probably... Do we stick them in App::Info::RDBMS::Informix::IDS, App::Info::RDBMS::Informix::XPS, etc? I'm not even sure I need to distinguish between the different servers - but it might be that the server (IDS for convenience) is installed in one place and the CSDK is installed in a separate place. As it happens, DBD::Informix is primarily concerned that there is a CSDK installation available on the compiling machine - it doesn't matter where the database server actually is as long as the connectivity is configured correctly.
Email [EMAIL PROTECTED] (in cc line) to continue the discussion over the weekend.
--
Jonathan Leffler ([EMAIL PROTECTED])
STSM, Informix Database Engineering, IBM Data Management
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"
David Wheeler <[EMAIL PROTECTED]>
01/16/2004 04:57 PM | To: Dave Rolsky <[EMAIL PROTECTED]> cc: Daisuke Maki <[EMAIL PROTECTED]>, datetime <[EMAIL PROTECTED]>, Jonathan Leffler/Menlo Park/[EMAIL PROTECTED] Subject: Re: Chinese/Japanese calendars - GMP is a pre-requisite |
On Jan 16, 2004, at 4:42 PM, Dave Rolsky wrote:
> There's App::Info and Alien for detecting non-Perl dependencies, but
> someone would have to code up the libgmp parts explicitly.
Well, Alien mainly exists as an idea in Arthur Bergman's head. (Maybe
he has been taken over by an alien?). It's goal is to provide packages
for installing non-Perl dependencies.
App::Info, OTOH, is designed to provide a unified interface for
determining if an external dependency is installed on the local system,
and if so, information about it (version number, binary location,
etc.). Check out App::Info::Lib::Expat for examples of how to create
your own subclass, and this link for instructions on subclassing:
http://search.cpan.org/dist/App-Info/lib/App/Info.pm#SUBCLASSING
Cheers,
David
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
<<inline: pic29164.gif>>
