Re: [PHP-DEV] Re: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgardconfig.m4)
On Mon, 19 Mar 2001, Rasmus Lerdorf wrote: Because the whole point of this was to make life easier on midgard users. So you're saying that every widely used external (at the moment) php-extension should be put into PHP CVS? :) If it will help users and there is demand for it, sure. Like the imlib2 extension for example. That probably should be in PHP CVS. Isn't php-gtk done like the way the PEAR (C) components should be done? At least that's how I compiled that extension. Separately from PHP. Using phpize. So I would guess having e.g. midgard outside PHP shouldn't matter at all? No, we need tighter integration. We want to be able to do something along the lines of "pear pear.php.net/midgard" and it would go and fetch the the component, build it and install it. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgardconfig.m4)
See pear/scripts/pear The framework is there. On Tue, 20 Mar 2001, Zeev Suraski wrote: At 02:04 20/3/2001, Rasmus Lerdorf wrote: No, we need tighter integration. We want to be able to do something along the lines of "pear pear.php.net/midgard" and it would go and fetch the the component, build it and install it. I completely agree with Andi about this. If it won't be simple, it will simply not be. We can start simple, and work our way up. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgardconfig.m4)
That's great, but it shouldn't be the starting point for the project... Jani is right that whenever we speak about separating PEAR, or putting extensions in it, it's always at some point in the future. Opensource projects usually start up and roll once they reach some critical mass, and waiting for a certain particular development to happen isn't usually beneficial. If there'll be people working on PEAR modules, the incentive for the 'pear' utility author will be much higher to make it work, and he may also have some support from others. It's been 14 months since PEAR was born, I think it may be a good idea to try and let it walk a bit. Sure, it's not like anybody is turning away code contributions. If someone has an idea for this PEAR infrastructure, it is more than welcome. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]