Re: Chinese/Japanese calendars - GMP is a pre-requisite
Dear Daisuke Maki, I've had an entertaining morning building Perl 5.8.3 and getting DateTime::Calendar::Japanese etc installed. Perl 5.8.3 itself was trivial - I'm glad to say. I ran into a bigger problem with DateTime::Calendar::Japanese etc -- they need the GMP (GNU Multi-Precision Math) library installed. I didn't have it, so I had to build it - twice, because the first time it opted to build 64-bit interfaces on a system (Solaris 8) where I still run mainly in 32-bit mode. With GMP built and installed, I could get Math::BigInt::GMP installed, and hence everything else. That was done first with 5.8.2 and then with 5.8.3. I don't know if there's an effective way for ensuring that a non-Perl prerequisite such as the GMP libraries are available. In DBD::Informix, my Makefile.PL does a lot of poking around to ensure that the prerequisite non-Perl ESQL/C product (library and headers) is both installed and usable - basically because I had so many people running into problems when it was not because they didn't know it was necessary. Also, when a test takes a long time, as many of yours do, you very kindly output a warning that the test will take a while, but it is really helpful to know when the test started, so you can easily determine how long the test has taken so far. So, once I had GMP installed (outside the Perl installation, but where Perl expects to find libraries), then the new modules installed OK. -- 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!
Re: Chinese/Japanese calendars - GMP is a pre-requisite
Hi, thanks for the feedback! GMP in itself is not necessary -- it's much faster if you have it, though. Did it *force* you to install GMP? I thought I put that requirement in the recommends parameter (like this: http://search.cpan.org/src/DMAKI/DateTime-Util-Calc-0.01/Build.PL). Perhpas I don't quite understand how Module::Build works... Please let me know. From the next release on, I should make sure that GMP is an optional package, and that Math::BigInt/Math::BigFloat is the bare minimum. After that I should be able to put some code in Build.PL that probes for GMP. --d I've had an entertaining morning building Perl 5.8.3 and getting DateTime::Calendar::Japanese etc installed. Perl 5.8.3 itself was trivial - I'm glad to say. I ran into a bigger problem with DateTime::Calendar::Japanese etc -- they need the GMP (GNU Multi-Precision Math) library installed. I didn't have it, so I had to build it - twice, because the first time it opted to build 64-bit interfaces on a system (Solaris 8) where I still run mainly in 32-bit mode. With GMP built and installed, I could get Math::BigInt::GMP installed, and hence everything else. That was done first with 5.8.2 and then with 5.8.3. I don't know if there's an effective way for ensuring that a non-Perl prerequisite such as the GMP libraries are available. In DBD::Informix, my Makefile.PL does a lot of poking around to ensure that the prerequisite non-Perl ESQL/C product (library and headers) is both installed and usable - basically because I had so many people running into problems when it was not because they didn't know it was necessary. Also, when a test takes a long time, as many of yours do, you very kindly output a warning that the test will take a while, but it is really helpful to know when the test started, so you can easily determine how long the test has taken so far. So, once I had GMP installed (outside the Perl installation, but where Perl expects to find libraries), then the new modules installed OK. -- 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!
Re: Chinese/Japanese calendars - GMP is a pre-requisite
Dear Daisuke Maki, When I was installing using CPANPLUS, it went off and automatically tried to install Math::BigInt::GMP, and that process failed because I didn't have GMP amongst my libraries. Now, that might be because it was 'recommended' rather than 'optional', or it may be for another reason. I wasn't asked whether to install it - it just went ahead and tried to do so. I'll let you see any settings you need to see if they'll help you. When you build Perl 5.8.3, could you experiment with disabling your GMP installation (move the library out of its normal position) and see what happens? If Math::BigInt::GMP isn't yours, then maybe we need to report the trouble to the maintainer(s) of M::BI::GMP? On the logarithmic scale of disasters (1 didn't happen to 10 the universe ended), this registers at 1.2 - not a massive one. But the out-of-box experience is not as enjoyable when you have to go and manually install something to get the automatic install to complete. -- 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! Daisuke Maki [EMAIL PROTECTED] Daisuke Maki [EMAIL PROTECTED] 01/16/2004 03:29 PM To: Jonathan Leffler/Menlo Park/[EMAIL PROTECTED] cc: datetime [EMAIL PROTECTED] Subject: Re: Chinese/Japanese calendars - GMP is a pre-requisite Hi, thanks for the feedback! GMP in itself is not necessary -- it's much faster if you have it, though. Did it *force* you to install GMP? I thought I put that requirement in the recommends parameter (like this: http://search.cpan.org/src/DMAKI/DateTime-Util-Calc-0.01/Build.PL). Perhpas I don't quite understand how Module::Build works... Please let me know. From the next release on, I should make sure that GMP is an optional package, and that Math::BigInt/Math::BigFloat is the bare minimum. After that I should be able to put some code in Build.PL that probes for GMP. --d I've had an entertaining morning building Perl 5.8.3 and getting DateTime::Calendar::Japanese etc installed. Perl 5.8.3 itself was trivial - I'm glad to say. I ran into a bigger problem with DateTime::Calendar::Japanese etc -- they need the GMP (GNU Multi-Precision Math) library installed. I didn't have it, so I had to build it - twice, because the first time it opted to build 64-bit interfaces on a system (Solaris 8) where I still run mainly in 32-bit mode. With GMP built and installed, I could get Math::BigInt::GMP installed, and hence everything else. That was done first with 5.8.2 and then with 5.8.3. I don't know if there's an effective way for ensuring that a non-Perl prerequisite such as the GMP libraries are available. In DBD::Informix, my Makefile.PL does a lot of poking around to ensure that the prerequisite non-Perl ESQL/C product (library and headers) is both installed and usable - basically because I had so many people running into problems when it was not because they didn't know it was necessary. Also, when a test takes a long time, as many of yours do, you very kindly output a warning that the test will take a while, but it is really helpful to know when the test started, so you can easily determine how long the test has taken so far. So, once I had GMP installed (outside the Perl installation, but where Perl expects to find libraries), then the new modules installed OK. -- 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! inline: graycol.gifinline: ecblank.gifinline: pic26071.gif
Re: Chinese/Japanese calendars - GMP is a pre-requisite
On Fri, 16 Jan 2004, Jonathan Leffler wrote: When I was installing using CPANPLUS, it went off and automatically tried to install Math::BigInt::GMP, and that process failed because I didn't have GMP amongst my libraries. Now, that might be because it was 'recommended' rather than 'optional', or it may be for another reason. I wasn't asked whether to install it - it just went ahead and tried to do so. I'll let you see any settings you need to see if they'll help you. CPANPLUS treats recommended as required, I think. ended), this registers at 1.2 - not a massive one. But the out-of-box experience is not as enjoyable when you have to go and manually install something to get the automatic install to complete. The real problem here, I think, is that CPANPLUS (and CPAN.pm as well) don't really support Module::Build's nice features, like distinguishing between required and recommended dependencies. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Chinese/Japanese calendars - GMP is a pre-requisite
Fair enough - I'll wait for the digest to appear and then lob a report to the CPANPLUS maintainers. That'd be Monday now. And, I suppose, it might be sensible to let the Math::BigInt::GMP people know there are problems when their code is automatically installed on a system without GMP. There's probably not much they can do except improve the error messages - if GMP is not there, their module isn't likely to work. -- 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! Dave Rolsky [EMAIL PROTECTED] Dave Rolsky [EMAIL PROTECTED] 01/16/2004 03:55 PM To: Jonathan Leffler/Menlo Park/[EMAIL PROTECTED] cc: Daisuke Maki [EMAIL PROTECTED], datetime [EMAIL PROTECTED] Subject: Re: Chinese/Japanese calendars - GMP is a pre-requisite On Fri, 16 Jan 2004, Jonathan Leffler wrote: When I was installing using CPANPLUS, it went off and automatically tried to install Math::BigInt::GMP, and that process failed because I didn't have GMP amongst my libraries. Now, that might be because it was 'recommended' rather than 'optional', or it may be for another reason. I wasn't asked whether to install it - it just went ahead and tried to do so. I'll let you see any settings you need to see if they'll help you. CPANPLUS treats recommended as required, I think. ended), this registers at 1.2 - not a massive one. But the out-of-box experience is not as enjoyable when you have to go and manually install something to get the automatic install to complete. The real problem here, I think, is that CPANPLUS (and CPAN.pm as well) don't really support Module::Build's nice features, like distinguishing between required and recommended dependencies. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ inline: graycol.gifinline: ecblank.gifinline: pic23067.gif
Re: Chinese/Japanese calendars - GMP is a pre-requisite
On Fri, 16 Jan 2004, Jonathan Leffler wrote: And, I suppose, it might be sensible to let the Math::BigInt::GMP people know there are problems when their code is automatically installed on a system without GMP. There's probably not much they can do except improve the error messages - if GMP is not there, their module isn't likely to work. There's App::Info and Alien for detecting non-Perl dependencies, but someone would have to code up the libgmp parts explicitly. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
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
Re: Chinese/Japanese calendars - GMP is a pre-requisite
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] 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.gifinline: ecblank.gifinline: pic29164.gif
Re: Chinese/Japanese calendars - GMP is a pre-requisite
On Jan 16, 2004, at 5:38 PM, Jonathan Leffler wrote: 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. No, probably not. DBD::Pg has done this. 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? I would do it the way we did it in DBD::Pg: Put it in t/lib: geertz% find t/lib | grep -v CVS t/lib t/lib/App t/lib/App/Info t/lib/App/Info/Handler t/lib/App/Info/Handler/Prompt.pm t/lib/App/Info/Handler.pm t/lib/App/Info/RDBMS t/lib/App/Info/RDBMS/PostgreSQL.pm t/lib/App/Info/RDBMS.pm t/lib/App/Info/Request.pm t/lib/App/Info/Util.pm t/lib/App/Info.pm Then you can just use it in Makefile.PL like this: use File::Spec; use lib File::Spec-catdir(qw(t lib)); use App::Info::RDBMS::Informix; Or copy the funky code from DBD::Pg's Makefile.PL (designed to support systems without File::Spec). 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. No, but it's not a bad idea. I'll think about adding it. You can always add it to your subclass, of course. 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? Sure, if you want. But I think I would make those lowercase, just to adhere to the typical Perl style. App::Info::HTTPD::Apache has its own methods that extend those defined by App::Info. 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? Sure, that makes sense to me. Although maybe libraries should just go into App::Info::Lib. 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. It's up to you to decide how much of the Informix suite you want to support. I'd welcome any contribution. And, yeah, I think it'd be cool to put it on CPAN, too, even if you do include it with DBD::Informix. Cheers, David
Re: Chinese/Japanese calendars - GMP is a pre-requisite
On Fri, 16 Jan 2004, David Wheeler wrote: I would do it the way we did it in DBD::Pg: Put it in t/lib: Why not use Module::Install? -J --
