On Thu, Jan 7, 2010 at 11:47 PM, David E. Wheeler wrote:
* I don't see how a Makefile can be optional if you need it to build extensions
Hrm. Well you can upload scripts to CPAN. Did you know that? CPAN.pm doesn't know what to do with them, but they're there. I was just trying to keep things as open as possible. Might end up requiring it anyway, for the reasons you cite.
If CPAN required an Makefile.PL/Build.PL, then the clients would know
what do with scripts (i.e. install them!). There are raw .pm files on
CPAN, too. CPAN.pm generates a Makefile.PL for those.
Will have to check that out. I plan to steal everything I can can from PAUSE, CPAN, CPAN.pm, CPANPLUS, and JSAN::Client.
See File::Rsync::Mirror::Recent
* Define a "minimum API" between pgan and make, including arguments
that all Makefiles must support.  You want to avoid the soup of
arguments that EU::MM and M::B have built up.  Do you need "make
installdeps"?  Do you need an equivalent to INSTALL_BASE?  Standardize
these now.
I'm not doing that part. I'm relying completely on PGXS, which is the Makefile included in PostgreSQL builds (postgresql-devel packages), to supply all that stuff. I don't want to go near the actual build system. Way too many bikeshed colors there and not my area of expertise in the slightest.
Yes, but you're talking about various PGXS extensions people might
add. I'm saying that you should be explicit about what is supported
and what not. (E.g. the pgan client will support PGXS version X.YZ)
[Ed. note: If CT2.0 migration happens on schedule, a common CPAN/PLUS
config system may be my QA hackathon project.]
I'll be at OSCON for sure!
I may try to go this year as I've never been and some of the CPAN and
CPAN Testers developments would be fun to talk about.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 11 | next ›
Discussion Overview
groupcpan-workers @
postedJan 7, '10 at 10:36p
activeJan 8, '10 at 6:04p



site design / logo © 2021 Grokbase