On Thu, Jan 7, 2010 at 11:47 PM, David E. Wheeler <da...@kineticode.com> 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. David
