On Tuesday 18 May 2004 17:33, Joshua D. Drake wrote:
> > But most binary packages do, and they are the ones I'm talking about.
> > And surely you do not advocate that, in order to build PL/PHP, the
> > packagers instead disable the client side support in PHP?
> Of course not, but I still don't see your point. plPHP doesn't need
> PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using
> plPHP...
> PHP doesn't even need to be installed for plPHP to work... You just
> need the source tree for building.
So you then have to build PHP twice, in an RPM build environment. You mean I
can't just have the headers installed to build plPHP? So, follow the
sequence of the RPM building events:
1.) Build PHP without PostgreSQL client support.
2.) Build PostgreSQL
3.) Build plPHP
4.) Build PHP with PostgreSQL client support.
The Perl situation is totally different, since the Perl client is not part of
the Perl source tree. The 4-step I mention above would never be followed by
any distributions, who would probably just not build plPHP to keep from
having the circular dependency.
See, in the RPM build environment for self-hosting distributions, I would have
to pull in the entire PHP source distribution during the PostgreSQL build.
Keeping that synchronized with the PHP version that is the main one
distributed would be a major pain.
Better would be getting plPHP so that it doesn't need the PostgreSQL source
tree, but just needs the development headers (with server-side) installed.
Then there is no circular build dependency. Then I just:
1.) Build PostgreSQL
2.) Build PHP (with PostgreSQL client support)
3.) Build plPHP (with PostgreSQL SPI support, or maybe even PostgreSQL client
support for cross database queries? :-))
Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how you
solved the circular dependency.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu