Re: towards a 2.07 release
Joe Schaefer wrote: 1) leave things as-is, which allows the cpan client to sift through the generated Makefile in order to pursue unsatisfied prereqs, or 2) change back the warn calls to die, which will confuse the cpan client, but will allow human users to figure out exactly what needs to be done in order for the build to continue. I think Stas and I both were forgetting #1 unless I just don't recall it. Could we not distrubute a dummy Makefile that's gets overwritten by Makefile.PL and this dummy makefile does nothing other then have dependency information for CPAN? Assuming, the above is a bad idea, [I don't like it] Do not more users install libapreq (v2 at least) manually? 2 is inconvient for CPAN, but failsafe -- at least when it does fail, you'll get a real error. You get some rather interesting failures if say mod_perl2.pm wasn't installed. So if I'm force to choose, I vote #2. HTH I still owe Makefile.PL work and INSTALL static build updating... If I just had time... -- END What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/ Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com http://www.liquidation.com http://www.uksurplus.com http://www.govliquidation.com http://www.gowholesale.com
Re: towards a 2.07 release
Edward J. Sabol wrote: It seems to me that both are desirable under different circumstances. Does it make sense to add an option to configure.pl (--die-if-prereqs-fail?) which controls this? You would think this -- but no. 1) You have know it exists and remember to specify it. of course you would say a smart sys admin or us would do ./configure --help first but even if you do, you usually only look at the last page, unless you know there is an option you have find the name of i.e. jpeg support for GD2.pm [I happen to maintain its FreeBSD port, hence the example] IMHO Most of the people on apreq-dev@ are contributors, power users, or committers. I believe we would want to target those left out of this equation. aka I just want to be able to use libapreq2 to retrieve query paramters instead of CGI under mod_perl. -- END What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/ Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com http://www.liquidation.com http://www.uksurplus.com http://www.govliquidation.com http://www.gowholesale.com
Re: svn commit: r331895 - in /httpd/apreq/trunk: INSTALL STATUS
[EMAIL PROTECTED] wrote: Author: joes Date: Tue Nov 8 13:27:59 2005 New Revision: 331895 URL: http://svn.apache.org/viewcvs?rev=331895view=rev Log: static builds stopped working when we moved to multi-env. since noone knows how to make them work, stop documenting the process and mark it as a todo. Well that definetely saves me some time! :) Thanks -- END What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/ Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com http://www.liquidation.com http://www.uksurplus.com http://www.govliquidation.com http://www.gowholesale.com
Re: towards a 2.07 release
On Tue, 8 Nov 2005, Joe Schaefer wrote: [ ... ] What's the consensus of the group on this issue? Introducing another prereq, possibly on CPAN itself, seems like a bad idea to me. I like the fact that the current build system is cpan- friendly, but I also appreciate the simplicity of having the build fail immediately on an unsatisfied prereq. So I don't know how to proceed at this point. We could either 1) leave things as-is, which allows the cpan client to sift through the generated Makefile in order to pursue unsatisfied prereqs, or 2) change back the warn calls to die, which will confuse the cpan client, but will allow human users to figure out exactly what needs to be done in order for the build to continue. Opinions? There are good arguments for both ways, but if I were to choose, I'd go for leaving things as they are - I think, currently, one could install libapreq2 entirely through the CPAN/CPANPLUS shells, including installing any prerequisites (except for mod_perl, probably, as this can't easily be done through the CPAN/CPANPLUS shell). This feature might prove quite useful to many. The fact that the build process doesn't die for manual installations in cases of unsatisfied prerequisites is no different than the usual CPAN distribution, so users who do things manually should be used to catching the warnings about unsatisfied prerequisites and following them up by hand. -- best regards, randy