Re: towards a 2.07 release

2005-11-09 Thread Philip M. Gollucci

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

2005-11-09 Thread Philip M. Gollucci

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

2005-11-09 Thread Philip M. Gollucci

[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

2005-11-09 Thread Randy Kobes

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