Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68574
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.174 as permitted sender)
MIME-Version: 1.0
Sender: jdavidlists@gmail.com
In-Reply-To: <CALJZF3iZ5MviokCJJ8THawVUzP6S5rPqFN5-7bn7ASwAK-rK7Q@mail.gmail.com>
References: <CABXB=RS6uL-d+0HbPpYxczw7jeijxu4s1TW5Lp_8fDvmafXS0w@mail.gmail.com>
	<CAESVnVoB-38am-2bWfCYcCKKjiPVGUP34aYjdMADsR3inijBBA@mail.gmail.com>
	<CABXB=RQKhFxCRmOO1QhpejX5EvaDfjE+sK9ybTFV-On0+ukuag@mail.gmail.com>
	<CAESVnVr86ZYYUcqUwLCQ0WPzLFpah6dW9H+mAucc7F=jsubarA@mail.gmail.com>
	<CABXB=RSZyWZmVma5pmnGXzhfvCNMDAsWkKKMs8UT_R1F5e0-QQ@mail.gmail.com>
	<CABXB=RTUsoHLqtu=eo98P-OmeEbW8N+t=HD9duNtJF_nJYY7sg@mail.gmail.com>
	<CAESVnVqxuqcm6PeoS5=hVLOE8Mex-zNtAjhaAvjyCTYNO4ZcQQ@mail.gmail.com>
	<CABXB=RRrC2FGHviD0MeZ=OUEX-ra3HAS8RkZ6CQGaLRiYjCurg@mail.gmail.com>
	<CALJZF3iZ5MviokCJJ8THawVUzP6S5rPqFN5-7bn7ASwAK-rK7Q@mail.gmail.com>
Date: Mon, 19 Aug 2013 19:17:33 -0400
Message-ID: <CABXB=RQFaBOGPce48MNArLPsYZVfjnSeTWP=uS0E_LRV5=5RJw@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Interest in a "null" SAPI for embedding?
From: j.david.lists@gmail.com (J David)

On Mon, Aug 19, 2013 at 3:59 PM, Michael Wallner <mike@php.net> wrote:
> I think it all was about to be as standalone as possible, e.g. you
> could have a CLI with builtin readline/pcntl/whatelse extensions,
> while mod_php could be kept lean of that and include an
> opcache/whatelse instead.

To stick with your example, of CLI and mod_php -- a good choice as
it's likely the most common combo -- when linking to a common
libphp5.so, the recommended methodology would be to build in only the
functionality required by both, then load the rest as extensions from
php-cli.ini or php.ini, respectively.  This seems like the way it is
generally done anyway?

Is doing it this other way a thing that people actually do?

> So, I'm not sure if a libphp.so is actually something we want
> unconditionally... maybe if it wasn't --enable-null but something like
> --enable-libphp, which would create a libphp.so  which would be used
> to link all of the specified SAPIs.

That's essentially how I interpreted Sara's suggestion, with possibly
some variance on whether or not this would be the default behavior.
If the --enable-shared-phplib (or whatever) flag weren't present, the
alternative would be to build a static library and then link your SAPI
selections against that.  The only difference in that scenario is that
the static library could be (optionally and probably not by default)
installed as libphp5.a to allow statically-linked independent SAPI's.
That should produce default behavior almost indistinguishable from
today.

> Now that example actually points to a problem, what if I mix case 2 and 3=
?
> ./configure --enable-libphp --enable-cli --disable-cgi ...
> ./configure --enable-libphp --with-apxs ...
>
> Where "=85" could be f.e. enable-maintainer-zts or enable-debug?

This concern (coexistence of conflicting settings/versions) seems very
similar to this:

On Mon, Aug 19, 2013 at 4:15 PM, Johannes Schl=FCter
<johannes@schlueters.de> wrote:
> For Unix I'm not sure it is good - it makes it complex to run multiple
> PHP versions next to each other which is not only relevant for
> developers but also hosters offering multiple versions.

From the standpoint of major versions, versioning the library (e.g.
libphp55.so, libphp-5.5.so) seems sensible. It doesn't seem reasonable
to expect ABI/SPAI compatibility between branches.  One could go as
far as libphp55.so.2 for 5.5.2, though that might be overkill.

Centrally installing one libphp55.so (e.g. into /usr/lib or
/usr/local/lib) would still limit one to one set of build options, but
as that is already largely true of centralized installations.
Typically, php.ini needs to be different between development and
production builds of the same version, for example. Or some/all of the
extensions may need to be built with different settings, etc.

However, in practice, this is not a problem we have encountered while
running 5.3, 5.4, 5.5 and master alongside each other, often with
multiple revisions within each major version and devel/debug vs.
production variants of the same version.

That's because we use a different --prefix for each.  Then, to link to
a specific build's libphp5.so created with null-sapi, we use the rpath
flag at link time.  This has proved to be a good strategy.  However,
we were doing this before we switched to this build methodology,
because the speed bump of inter-version collisions had already been
hit. :)

In the worst case scenario, an additional flag like
--with-shlib-suffix=3D55xyzpdq (producing/linking to libphp55xyzpdq.so)
passed to PHP or SAPI builds would probably allow sufficiently
infinite variety. :)  Such an option would choose a sensible default
("55") for most people.

Thanks!