PL/php

You are not proposing to bundle PHP and PL/PHP into a single source tree, are you? I think distribution is about providing a binary package, so what do we need sources for anyway?

The way I think we should choose here is to package the pl/php binary built against the static embed library. It seems to work well on Linux and Mac OS X, although nobody tested this on more exotic platforms (like Windows).

On 05/21/2011 09:24 PM, plphp-tickets@lists.commandprompt.com wrote:

Issue #5256 has been updated by Alexey Klyukin.

You are not proposing to bundle PHP and PL/PHP into a single source tree, are you? I think distribution is about providing a binary package, so what do we need sources for anyway?

Yes I was actually considering that, e.g; we target a specific version
of PHP, and that version is part of our build process for PL/PHP (even
if it is just a script that pulls that version from the web and compiles
it with the proper flags).

We need sources for those platforms we don't build binaries for.

The way I think we should choose here is to package the pl/php binary built against the static embed library. It seems to work well on Linux and Mac OS X, although nobody tested this on more exotic platforms (like Windows).

Oh I agree with this too, I was actually talking about something different.

JD

----------------------------------------
Discussion #5256: Creating a PL/php distribution
https://public.commandprompt.com/issues/5256

Author: Joshua Drake
Status: New
Priority: Normal
Assignee:
Category:
Target version:
Resolution:

Since we need PHP source to create plphp (due to no one shipping as embed), perhaps we should just include the source as part of the download of php and have a predefined configure that deals with all of it for people. Thoughts?

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579

Joshua Drake wrote:

Yes I was actually considering that, e.g; we target a specific version
of PHP, and that version is part of our build process for PL/PHP (even
if it is just a script that pulls that version from the web and compiles
it with the proper flags).

I think we can do this, but that shouldn't be the primary way of compiling PL/PHP, i.e. those who managed to install embed by themselves should be able to build PL/PHP without downloading anything. I'm ok with a script for downloading PHP sources and building them in a proper way, but not with adding PHP and PL/PHP sources together in a single tarball.

There have been several projects that did things like this in the past, for example embedding zlib, or Xpdf, or (gasp) Mozilla. The result is always disastrous -- you have to keep track of upstream security problems, upgrades, you're incompatible with a future version that the user installs long time after he got your package running. You get bug reports because he installs the new version and the new features are not available in your package. And so on.

I think we should stay as far away from this solution as we can, because it's going to cost us a lot of effort down the road.