On Mon, Aug 19, 2013 at 7:49 PM, Johannes Schlüter
wrote:
> Ah, there's another thing to mind: Extensions can be marked as "cli
> extensions", if statically compiled they become only part of the CLI
> binary, not other SAPIs. Think readline & pcntl.
The logical expectation then would be not to in
On Mon, 2013-08-19 at 19:17 -0400, J David wrote:
>
> 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 lo
On Mon, Aug 19, 2013 at 3:59 PM, Michael Wallner 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
On Mon, 2013-08-19 at 14:12 -0400, J David wrote:
> On Fri, Aug 16, 2013 at 9:15 PM, Sara Golemon wrote:
> > Right, gotcha. I think ideally someone should put in the grunt work to do
> > what you suggested: Build libphp5.so all the time, then link up
> > php/mod_php5.so/etc... against that as a s
On 19 August 2013 20:12, J David wrote:
> The big preliminary question for me would be, "Is there a specific
> design reason why it isn't currently done this way?" PHP already
> requires shlib's that depend on shlib's, so that functionality is
> probably universally available, but I can't shake t
On Fri, Aug 16, 2013 at 9:15 PM, Sara Golemon wrote:
> Right, gotcha. I think ideally someone should put in the grunt work to do
> what you suggested: Build libphp5.so all the time, then link up
> php/mod_php5.so/etc... against that as a shared system library (which in
> turn other programs or SA
Ah, I see. I wasn't taking "null" quite literally enough. :)
That sounds pretty awesome to me. Assuming the implementation looks good
you'd get my vote.
On Fri, Aug 16, 2013 at 11:03 AM, J David wrote:
> On Fri, Aug 16, 2013 at 12:40 PM, Sara Golemon wrote:
> > Apart from managing lifecycle
On Fri, Aug 16, 2013 at 12:40 PM, Sara Golemon wrote:
> Apart from managing lifecycles, the SAPI is also resposible for things like
> directing I/O between the host application, how does null-sapi handle this?
It doesn't. It provides no SAPI functionality at all (hence "null").
Its only purpose
On Fri, Aug 16, 2013 at 12:55 PM, Johannes Schlüter
wrote:
> I was successful by using embedded SAPI for that and ignoring all things
> from php_embed.[ch]. Sure this gives few extra symbols and a few bytes
> of unneeded code but works fine.
Yes, exactly. This is a cleaner/more formal way of doi
To try it out, here's a hacky little Makefile you can use to build the
CLI SAPI against the null shlib:
http://pastebin.com/3FxWhZn4
Resulting in:
$ ls -l phpn
-rwxrwxr-x 1 me staff 113669 Aug 17 00:13 phpn
$ ldd phpn
phpn:
libphp5.so => /usr/local/php/5.6-dev/lib/libphp5.so (0x2808)
libc
On Fri, Aug 16, 2013 at 5:28 PM, Sara Golemon wrote:
> Ah, I see. I wasn't taking "null" quite literally enough. :)
>
> That sounds pretty awesome to me. Assuming the implementation looks good
> you'd get my vote.
"Implementation" might be a little generous… it's a config.m4 file, a
header file
On Fri, 2013-08-16 at 12:36 -0400, J David wrote:
> Our solution was to develop a new pseudo-SAPI we call the null SAPI.
> All it does is build a complete libphp5.so with no SAPI-related
> structures or functions in it at all. Then we can build our real
> embedded SAPI -- with all its extra depend
Right, gotcha. I think ideally someone should put in the grunt work to do
what you suggested: Build libphp5.so all the time, then link up php/
mod_php5.so/etc... against that as a shared system library (which in turn
other programs or SAPIs could link against).
I'm not sure if anyone has the time
Apart from managing lifecycles, the SAPI is also resposible for things like
directing I/O between the host application, how does null-sapi handle this?
On Fri, Aug 16, 2013 at 9:36 AM, J David wrote:
> Hello,
>
> We recently successfully embedded PHP into our application using an
> approach bas
Hello,
We recently successfully embedded PHP into our application using an
approach based on the embed SAPI.
However, our application is large and complex, written entirely in
C++, requires a bit more functionality than the embed SAPI offers.
(As an example, however, it was invaluable.) So we ne
15 matches
Mail list logo
