Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76316
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tobin.nl designates 208.97.132.208 as permitted sender)
Message-ID: <53DDFCC8.6080905@tobin.nl>
Date: Sun, 03 Aug 2014 11:11:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <A325343A-06E8-4A4C-97E6-652EFCD51AE6@googlemail.com>
In-Reply-To: <A325343A-06E8-4A4C-97E6-652EFCD51AE6@googlemail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Custom build rule
From: bas@tobin.nl (Bas van Beek)


Op 03-08-14 om 02:24 schreef Ingwie Phoenix:
> Hello internals!
>
> I have almost completed a SAPI, that allows NodeJS scripters to enable =
PHP from within their HTTP servers.
>
> Originally, I wanted to write this extension just for my own use, but a=
s I see the many =84dirty=93 hacks that people use to run PHP inside thei=
r http server, I decided to make this extension more available, once its =
done and working.
If "dirty" means that each different HTTP server needs a SAPI with very=20
specific code for that HTTP server and often the first iteration of such=20
a SAPI is done by modifying the embed SAPI to suit the HTTP server's=20
specifics, then "dirty" is kind of logical and inevitable. The lack of=20
online documentation about the internals make people often "butcher" an=20
existing SAPI to fit their needs.

Each HTTP server has its own way of dealing with exchanging data=20
structures for incoming and outgoing HTTP headers, cookies, URL to "file=20
object & GET variables" parsing, POST data, etc. That's why PHP has the=20
sapi_module_struct which allows you to interface between PHP and your=20
HTTP server by use of attaching callback functions for the items you=20
wish to integrate. Basically each SAPI is an implementation of those=20
callback functions. The official Embed and my Embed2 project you=20
evaluated are different beasts. They are not meant to integrate with a=20
HTTP server but with applications desiring to allow PHP scripts in a non=20
web server context. They allow you to go in and out of PHP execution=20
context and mix with C / C++ code without actually dealing with a single=20
isolated PHP script run. Of course they can be used to start a new SAPI=20
for a specifically flavored HTTP server but they do add boilerplate not=20
needed if only desiring the integrate with a "regular" HTTP server.

> However, the build process is a bit complicated, as it plays between wo=
rlds; the autoconf based PHP build system and the GYP driven node extensi=
on build system. So far, I am working on the first solution: Building the=
 extension using PHP=92s build mechanism.
>
> As I know the procedure for building nodejs addons by their commands, I=
=92d just need to add a custom action/rule to the build, that builds a st=
atic library/bundle with .node as file extension isntead of the usual .so=
/.dll.
>
> How do I do that? Its two C++ files (tinythread.cpp, v8php.cc) that nee=
d to be compiled. v8php.cc houses the entire SAPI code as well as the nod=
ejs bindings.
>
> And as a side note: When the user has previously built PHP with ZTS and=
 Embed-SAPI, so that libphp5 is built, can they just link a SAPI against =
that? I see that php-config lists the SAPIs, and I wondered if there is a=
 generated file that lists/depends on all the SAPIs.
See my above comment on SAPI's. Basically once a libphp5 has been built,=20
it has implementations (or not) for the various integration touch points=20
(send_headers, read_post, read_cookies, etc.). The libphp5 is a library=20
with the user selected SAPI implemented. So to answer your question, no=20
you can't link another SAPI against it and you've asked the wrong=20
question. It seems you treat SAPIs as if they are regular PHP extensions=20
you should add them after a PHP build. They are not and you should also=20
treat them differently.

You have two choices. Add the integration code on the PHP project end or=20
the HTTP Server project end. The majority of SAPI's do the integration=20
piece on the PHP end and I suggest you do the same for your integration.=20
If you wish to go the other route you could build an extremely bare bone=20
PHP SAPI wrapper that implements nothing and leave the implementation=20
details of the sapi_module_struct and php initialization to the HTTP=20
Server project piece.

The best way to build a PHP Library with your own SAPI is to make sure=20
you've implemented the config.m4 and config.w32 files, add the SAPI=20
project to the PHP source tree under the sapi directory and run=20
./buildconf --force to generate configure files including the option to=20
build your SAPI. Now you can build your libphp5 library with your SAPI=20
flavor in the same way as the other SAPIs.

> Kind regards,
> Ingwie
kind regards,

Bas van Beek