FAQ
Hi!

We have today been asked by Debian and Ubuntu Maintainers to merge our
code up to PHP repository.
They have stated that they want to see the fpm sapi variant officially
supported.

It would be nice to hear what you guy's official decision would be
about something like this.
Here are some details about the FPM Project, and it's current status:

Andrei has done very clean, pristine code since forking the fcgi-sapi
and moving it forward in the 0.602.
I have been involved recently in this simply as a packager for the new
0.6 line of FPM Project.

We maintain ourselves as a seperate project on launchpad, and have not
submitting any code to you guys (PHP).
But since this request from debian/ubuntu, i guess we need for some
type of upstream sync or import process.

We are versioned in bzr and github.

## Autoconf

This project relies upon its own versions of the autoconf toolset to
generate its `./configure` script. To use autoconf, then run
`./build-autotools` which will install it locally in the directory. If
`./build-autotools` fails we have more information in
autoconf.markdown.

## Build process

Compilation is pretty straightforward and hassle-free. The make
process can be described as:

1) Compile the php sources into object files in the php build directory
2) Compile the fpm sources into object files in the fpm build directory
3) Link all the php object file with these fpm object file together
4) Output: Static php5 binary, which is php base and using the fpm's
version of fcgi-SAPI as frontend

Fpm is mixed into php at the link-level. This de-couples the fpm
sources, making the process manager part somewhat less sensitive to
changes in the php project. PHP-FPM is derived from the fcgi-sapi. We
no longer patch directly onto php-maintained files. Instead there are
3 similar counterpart files from sapi/cgi and fpm's sapi are
periodically synced to them. Libevent library is included for the
process management.

## Licence
Fpm has a very minimal licence. Fpm-sapi is a php license. The bundled
Libevent library is OpenBSD.
Please Contact Andrei Nigmatulin regarding any further licensing questions.
You should otherwise credit Andrei Nigmatulin as the author of /fpm sources.

## Compatibility

Fpm 0.6.3+ is coming soon for the following versions of php:

php-5.2.10+ (ready)
php-5.3.any (definitely coming this week)
php-6.0 /trunk (may be this week also, if no hitch)

The script in our src tree 'generate-fpm-patch' is a possible way to
sync changes.
Or perhaps there's a better way to get from bzr into a subtree as svn.

The project's sub-tree is;
config/
libevent/
man/
src/
src/fpm/
src/sapi/

Would we be required to change the layout of our project's subtree?
And then which directory can it exist?

a) ext/fpm/
b) fpm/
c) sapi/fpm/ ?


Again, please any thoughts / discussion welcome.


Best regards,

dreamcat4
dreamcat4@gmail.com

Search Discussions

  • Rasmus Lerdorf at Sep 9, 2009 at 12:01 am
    This has been discussed before. See:
    http://news.php.net/php.internals/44476
    http://news.php.net/php.internals/44480
    http://news.php.net/php.internals/44484
    http://news.php.net/php.internals/44485

    Basically it comes down to figuring out whether to extend the existing
    FastCGI SAPI to support the process management in FPM, or add it as a
    separate SAPI.

    -Rasmus

    dreamcat four wrote:
    Hi!

    We have today been asked by Debian and Ubuntu Maintainers to merge our
    code up to PHP repository.
    They have stated that they want to see the fpm sapi variant officially
    supported.

    It would be nice to hear what you guy's official decision would be
    about something like this.
    Here are some details about the FPM Project, and it's current status:

    Andrei has done very clean, pristine code since forking the fcgi-sapi
    and moving it forward in the 0.602.
    I have been involved recently in this simply as a packager for the new
    0.6 line of FPM Project.

    We maintain ourselves as a seperate project on launchpad, and have not
    submitting any code to you guys (PHP).
    But since this request from debian/ubuntu, i guess we need for some
    type of upstream sync or import process.

    We are versioned in bzr and github.

    ## Autoconf

    This project relies upon its own versions of the autoconf toolset to
    generate its `./configure` script. To use autoconf, then run
    `./build-autotools` which will install it locally in the directory. If
    `./build-autotools` fails we have more information in
    autoconf.markdown.

    ## Build process

    Compilation is pretty straightforward and hassle-free. The make
    process can be described as:

    1) Compile the php sources into object files in the php build directory
    2) Compile the fpm sources into object files in the fpm build directory
    3) Link all the php object file with these fpm object file together
    4) Output: Static php5 binary, which is php base and using the fpm's
    version of fcgi-SAPI as frontend

    Fpm is mixed into php at the link-level. This de-couples the fpm
    sources, making the process manager part somewhat less sensitive to
    changes in the php project. PHP-FPM is derived from the fcgi-sapi. We
    no longer patch directly onto php-maintained files. Instead there are
    3 similar counterpart files from sapi/cgi and fpm's sapi are
    periodically synced to them. Libevent library is included for the
    process management.

    ## Licence
    Fpm has a very minimal licence. Fpm-sapi is a php license. The bundled
    Libevent library is OpenBSD.
    Please Contact Andrei Nigmatulin regarding any further licensing questions.
    You should otherwise credit Andrei Nigmatulin as the author of /fpm sources.

    ## Compatibility

    Fpm 0.6.3+ is coming soon for the following versions of php:

    php-5.2.10+ (ready)
    php-5.3.any (definitely coming this week)
    php-6.0 /trunk (may be this week also, if no hitch)

    The script in our src tree 'generate-fpm-patch' is a possible way to
    sync changes.
    Or perhaps there's a better way to get from bzr into a subtree as svn.

    The project's sub-tree is;
    config/
    libevent/
    man/
    src/
    src/fpm/
    src/sapi/

    Would we be required to change the layout of our project's subtree?
    And then which directory can it exist?

    a) ext/fpm/
    b) fpm/
    c) sapi/fpm/ ?


    Again, please any thoughts / discussion welcome.


    Best regards,

    dreamcat4
    dreamcat4@gmail.com
  • Dreamcat four at Sep 9, 2009 at 1:14 am
    I'm 99% sure, this proposal this time around is for a seperate SAPI
    only. So that's not the question being asked here.
    The question is: Do you want fpm-sapi (or not)?

    On Wed, Sep 9, 2009 at 1:01 AM, Rasmus Lerdorfwrote:
    This has been discussed before.  See:
    http://news.php.net/php.internals/44476
    http://news.php.net/php.internals/44480
    http://news.php.net/php.internals/44484
    http://news.php.net/php.internals/44485

    Basically it comes down to figuring out whether to extend the existing
    FastCGI SAPI to support the process management in FPM, or add it as a
    separate SAPI.

    -Rasmus
  • Stanislav Malyshev at Sep 9, 2009 at 1:39 am
    Hi!
    The question is: Do you want fpm-sapi (or not)?
    If it applies cleanly to PHP and doesn't require changes in the core,
    then why not?
    But for that I guess there should be some build modifications that make
    common build (i.e., as for other modules - one runs configure/make and
    gets the binary) - is it possible? If so, then I see no problem making
    sapi/fpm.
    Not sure about bundling libevent though - does it have to be bundled?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Dreamcat four at Sep 9, 2009 at 2:43 am

    On Wed, Sep 9, 2009 at 2:23 AM, Stanislav Malyshevwrote:
    Hi!
    The question is: Do you want fpm-sapi (or not)?
    If it applies cleanly to PHP and doesn't require changes in the core, then
    why not?
    But for that I guess there should be some build modifications that make
    common build (i.e., as for other modules - one runs configure/make and gets
    the binary) - is it possible? If so, then I see no problem making sapi/fpm.
    Its coming with it's own ./configure. I think you can hang one
    configure script off from another because that's how fpm configures
    its libevent library. This would be much preffered way. However you'd
    then also have to be forwarding the fpm-specific configure flags
    onward from the main php configure script. Im not sure how to do that
    yet. But once the Makefile is created, then make-stage is like an
    automatic recursion thing isn't it?

    BTW all the debian maintainers asked for is the fpm sourcecode to be
    supplied in the php-src folder. (rather than created from a patch
    file). They said nothing about requiring to share the same build
    command. I mention this because it didn't represent any kind of
    technical issue for making a debian package. Indeed it seemed easier
    not to.
    Not sure about bundling libevent though - does it have to be bundled?
    Don't know. Libevent is frozen in there and a couple of files were
    modified with references back into the fpm headers.
    The Libevent was updated recently anyway, so its a pretty recent version.


    dreamcat4
    dreamcat4@gmail.com
  • Stanislav Malyshev at Sep 9, 2009 at 3:59 am
    Hi!
    Its coming with it's own ./configure. I think you can hang one
    I'd suspect most of what it's configure is doing is done by the php one
    too, and the rest can be converted to PHP's configure fragment. The
    thing is that if you want to have it in PHP tree, it won't look too good
    for it to have its own configure, no other SAPI does that and there's no
    reason to.
    As for bundling libevent, I have no idea if BSD code can be put in php
    tree... It'd be much nicer if these chanegs were merged into libevent -
    it seems to be pretty alive, 3 releases this year.
    yet. But once the Makefile is created, then make-stage is like an
    automatic recursion thing isn't it?
    If you do it by PHP standards, it is, but otherwise I don't know - let
    configure gurus on the list speak about it.
    file). They said nothing about requiring to share the same build
    command. I mention this because it didn't represent any kind of
    technical issue for making a debian package. Indeed it seemed easier
    not to.
    Well, PHP has certain rules and customs of how SAPIs are built. Of
    course, you can take PHP code and do whatever you like with it (if you
    not call the result PHP without permission :) but if it's going to be
    inside PHP tree then it should be organized by PHP rules. Otherwise PHP
    tree would be an incomprehensible mess.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Michael Shadle at Sep 9, 2009 at 4:08 am

    On Tue, Sep 8, 2009 at 8:58 PM, Stanislav Malyshevwrote:

    As for bundling libevent, I have no idea if BSD code can be put in php
    tree... It'd be much nicer if these chanegs were merged into libevent - it
    seems to be pretty alive, 3 releases this year.
    That's what I've been saying. If it's something that should be
    patched/changed in libevent, attack it there and just make it a
    dependency. No more packaging it together.
  • Sean finney at Sep 9, 2009 at 5:55 am

    On Wed, Sep 09, 2009 at 03:42:44AM +0100, dreamcat four wrote:
    Not sure about bundling libevent though - does it have to be bundled?
    Don't know. Libevent is frozen in there and a couple of files were
    modified with references back into the fpm headers.
    The Libevent was updated recently anyway, so its a pretty recent version.
    just FYI this will also be problematic. as some of the other php devs
    are probably well aware (hi pierre!), we have a pretty strict policy
    against using embedded libraries, even more so for embedded libraries
    that have been locally modified.


    sean
  • Pierre Joye at Sep 9, 2009 at 7:06 am
    hi,

    On Wed, Sep 9, 2009 at 7:55 AM, sean finneywrote:
    On Wed, Sep 09, 2009 at 03:42:44AM +0100, dreamcat four wrote:
    Not sure about bundling libevent though - does it have to be bundled?
    Don't know. Libevent is frozen in there and a couple of files were
    modified with references back into the fpm headers.
    The Libevent was updated recently anyway, so its a pretty recent version.
    just FYI this will also be problematic.  as some of the other php devs
    are probably well aware (hi pierre!), we have a pretty strict policy
    against using embedded libraries, even more so for embedded libraries
    that have been locally modified.
    I would like to see strict policies too about respecting upstream
    design decisions or implementations. But I won't hijack that thread to
    kill a dead cow :)

    Cheers,
  • Jani Taskinen at Sep 9, 2009 at 7:46 am

    On 09/09/2009 08:55 AM, sean finney wrote:
    On Wed, Sep 09, 2009 at 03:42:44AM +0100, dreamcat four wrote:
    Not sure about bundling libevent though - does it have to be bundled?
    Don't know. Libevent is frozen in there and a couple of files were
    modified with references back into the fpm headers.
    The Libevent was updated recently anyway, so its a pretty recent version.
    just FYI this will also be problematic. as some of the other php devs
    are probably well aware (hi pierre!), we have a pretty strict policy
    against using embedded libraries, even more so for embedded libraries
    that have been locally modified.
    Yeah, NO THANKS. We have enough of unmaintained code already. Since you
    want this fpm thing into upstream PHP releases, why not make the changes
    into libevent go upstream as well and then reconsider bundling, merging,
    etc.

    --Jani
  • Sean finney at Sep 9, 2009 at 8:56 am

    On Wed, Sep 09, 2009 at 10:46:53AM +0300, Jani Taskinen wrote:
    Yeah, NO THANKS. We have enough of unmaintained code already. Since
    you want this fpm thing into upstream PHP releases, why not make the
    changes into libevent go upstream as well and then reconsider
    bundling, merging, etc.
    that seems a natural corollary, yes. that or remove the need for making
    the local modifications in the first place. i'm not at all familiar
    with the fpm project so wasn't aware of this until it was brought up, and
    i don't know the specifics of how/why the library has been modified.

    i should also point out that it's not exactly that *I* want this to be
    included in php... all i know is that as a general rule when someone
    comes along saying "hey can you apply this huge patch for a new feature",
    i'm inclined to first point them at the upstream developers to try to
    get it sorted out there.

    this allows for a certain level of code review and the chance to get an
    idea of what you think of the feature, as well as potentially benefitting
    the entire php user base (if you take it) vs. the limited one of those
    using debian-derived php packages (if we take it). and if you don't
    like/want the patch, it would be good to know the reasons as it'd help
    us decide whether or not we want it too.


    sean

    --
  • Jani Taskinen at Sep 9, 2009 at 7:43 am

    On 09/09/2009 03:01 AM, Rasmus Lerdorf wrote:
    This has been discussed before. See:
    http://news.php.net/php.internals/44476
    http://news.php.net/php.internals/44480
    http://news.php.net/php.internals/44484
    http://news.php.net/php.internals/44485

    Basically it comes down to figuring out whether to extend the existing
    FastCGI SAPI to support the process management in FPM, or add it as a
    separate SAPI.
    As separate SAPI, wouldn't it duplicate a LOT of code, basically for
    nothing? I'd rather see the good parts of this merged into the
    one-and-only sapi/cgi/ code instead of creating yet another SAPI nobody
    maintains for real.

    --Jani


    -Rasmus

    dreamcat four wrote:
    Hi!

    We have today been asked by Debian and Ubuntu Maintainers to merge our
    code up to PHP repository.
    They have stated that they want to see the fpm sapi variant officially
    supported.

    It would be nice to hear what you guy's official decision would be
    about something like this.
    Here are some details about the FPM Project, and it's current status:

    Andrei has done very clean, pristine code since forking the fcgi-sapi
    and moving it forward in the 0.602.
    I have been involved recently in this simply as a packager for the new
    0.6 line of FPM Project.

    We maintain ourselves as a seperate project on launchpad, and have not
    submitting any code to you guys (PHP).
    But since this request from debian/ubuntu, i guess we need for some
    type of upstream sync or import process.

    We are versioned in bzr and github.

    ## Autoconf

    This project relies upon its own versions of the autoconf toolset to
    generate its `./configure` script. To use autoconf, then run
    `./build-autotools` which will install it locally in the directory. If
    `./build-autotools` fails we have more information in
    autoconf.markdown.

    ## Build process

    Compilation is pretty straightforward and hassle-free. The make
    process can be described as:

    1) Compile the php sources into object files in the php build directory
    2) Compile the fpm sources into object files in the fpm build directory
    3) Link all the php object file with these fpm object file together
    4) Output: Static php5 binary, which is php base and using the fpm's
    version of fcgi-SAPI as frontend

    Fpm is mixed into php at the link-level. This de-couples the fpm
    sources, making the process manager part somewhat less sensitive to
    changes in the php project. PHP-FPM is derived from the fcgi-sapi. We
    no longer patch directly onto php-maintained files. Instead there are
    3 similar counterpart files from sapi/cgi and fpm's sapi are
    periodically synced to them. Libevent library is included for the
    process management.

    ## Licence
    Fpm has a very minimal licence. Fpm-sapi is a php license. The bundled
    Libevent library is OpenBSD.
    Please Contact Andrei Nigmatulin regarding any further licensing questions.
    You should otherwise credit Andrei Nigmatulin as the author of /fpm sources.

    ## Compatibility

    Fpm 0.6.3+ is coming soon for the following versions of php:

    php-5.2.10+ (ready)
    php-5.3.any (definitely coming this week)
    php-6.0 /trunk (may be this week also, if no hitch)

    The script in our src tree 'generate-fpm-patch' is a possible way to
    sync changes.
    Or perhaps there's a better way to get from bzr into a subtree as svn.

    The project's sub-tree is;
    config/
    libevent/
    man/
    src/
    src/fpm/
    src/sapi/

    Would we be required to change the layout of our project's subtree?
    And then which directory can it exist?

    a) ext/fpm/
    b) fpm/
    c) sapi/fpm/ ?


    Again, please any thoughts / discussion welcome.


    Best regards,

    dreamcat4
    dreamcat4@gmail.com
  • Stanislav Malyshev at Sep 9, 2009 at 7:59 am
    Hi!
    As separate SAPI, wouldn't it duplicate a LOT of code, basically for
    nothing? I'd rather see the good parts of this merged into the
    one-and-only sapi/cgi/ code instead of creating yet another SAPI nobody
    maintains for real.
    If the code will be really the same exactly, then maybe it can be just
    reused (e.g. functions, etc.)? If not, then somewhat similar code I
    don't think is a problem if it's maintained, and if it's not then better
    have unmaintaned separate SAPI then unmaintained pieces of code inside
    of one of most used SAPIs :)
    In general, I'd consider changing sapi/cgi adding new potentially
    unstable hode rather high-risk, unless it can be very well isolated.
    sapi/cgi runs quite a lot of code...
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Jani Taskinen at Sep 9, 2009 at 8:01 am

    On 09/09/2009 10:53 AM, Stanislav Malyshev wrote:
    As separate SAPI, wouldn't it duplicate a LOT of code, basically for
    nothing? I'd rather see the good parts of this merged into the
    one-and-only sapi/cgi/ code instead of creating yet another SAPI
    nobody maintains for real.
    If the code will be really the same exactly, then maybe it can be just
    reused (e.g. functions, etc.)? If not, then somewhat similar code I
    don't think is a problem if it's maintained, and if it's not then better
    have unmaintaned separate SAPI then unmaintained pieces of code inside
    of one of most used SAPIs :)
    In general, I'd consider changing sapi/cgi adding new potentially
    unstable hode rather high-risk, unless it can be very well isolated.
    sapi/cgi runs quite a lot of code...
    Very good point. And I did consider only merging the _good_ parts of
    this thing. I haven't had time to check the code yet at all (quite busy
    at work right now) but there are some stuff it does we haven't generally
    considered the "job of PHP" before. The list of them is here:

    http://php-fpm.org/What_is_PHP-FPM

    --Jani
  • Michael Shadle at Sep 9, 2009 at 8:13 am

    On Wed, Sep 9, 2009 at 1:01 AM, Jani Taskinenwrote:

    Very good point. And I did consider only merging the _good_ parts of this
    thing. I haven't had time to check the code yet at all (quite busy at work
    right now) but there are some stuff it does we haven't generally considered
    the "job of PHP" before. The list of them is here:

    http://php-fpm.org/What_is_PHP-FPM
    Current:
    Proper termination of errant processes
    FastCGI pool configuration, management, proper child recycling
    Per-pool php.ini overrides

    Future:
    Adaptive process spawning (has been in the plans for a while but
    Andrei never got a chance to get around to finishing it)
    Hopefully some metrics/reporting
    Probably changing the configuration file syntax
    Per-pool specific php.ini file (basically just php-cgi -c, very simple
    addition to add)
    (look at the Wishlist page on the wiki...)

    Lots of room for improvement. I think it will help with resource
    management as well. Right now you have to arbitrarily assign how many
    children you want without any real way to measure if it's too many or
    too little.

    I had suggested this idea at one point - that is adding in only what
    is needed from PHP-FPM into PHP core and allowing the management of
    those hooks from an external tool developed and maintained separately
    (or through API calls) - then a variety of tools could manage the
    portions of the FastCGI SAPI that PHP-FPM does to terminate processes,
    spawn new children, and do whatever else was patched into PHP, and
    keep the management portion which is in charge of launching children,
    monitoring them, all that in its own standalone package. I see it as
    both allowing for more agile development on the management portion as
    it is lacking in a lot of features that we'd like to see (and not have
    to wait on PHP core's release cycle to get them in) and also can be
    packaged separately in distributions, much like spawn-fcgi is right
    now.

    Essentially it could be thought of as moving in the direction of
    spawn-fcgi (being standalone), just with more robust PHP
    functionality.
  • Stanislav Malyshev at Sep 9, 2009 at 8:29 am
    Hi!
    Very good point. And I did consider only merging the _good_ parts of
    this thing. I haven't had time to check the code yet at all (quite busy
    at work right now) but there are some stuff it does we haven't generally
    considered the "job of PHP" before. The list of them is here:

    http://php-fpm.org/What_is_PHP-FPM
    Exactly. That's why I don't have a problem of it being a separate SAPI -
    we have about 20, what harm could one more do? :) It's much safer this
    way. And if we discover merging into sapi/cgi really makes sense - at
    least we'd have code that already works with php, plays by php rules,
    etc. so it'd be much easier and safer.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Dreamcat four at Sep 9, 2009 at 9:45 am

    On Wed, Sep 9, 2009 at 9:18 AM, Stanislav Malyshevwrote:
    Exactly. That's why I don't have a problem of it being a separate SAPI - we
    have about 20, what harm could one more do? :) It's much safer this way. And
    if we discover merging into sapi/cgi really makes sense - at least we'd have
    code that already works with php, plays by php rules, etc. so it'd be much
    easier and safer.
    From outside this also seems like the correct route to take. A much
    better place from which to re-work any common codes.

    In regards to libevent library, it's probably enough discussions for
    now as we all seem in agreement. We shall see about getting libevent
    moved out from the fpm-0.6.4 sources and changed over to a libtool
    dependancy. I guess it can't be particularly very much work to solve.

    dreamcat4
    dreamcat4@gmail.com
  • Derick Rethans at Sep 9, 2009 at 9:58 am

    On Wed, 9 Sep 2009, dreamcat four wrote:

    On Wed, Sep 9, 2009 at 9:18 AM, Stanislav Malyshevwrote:
    Exactly. That's why I don't have a problem of it being a separate SAPI - we
    have about 20, what harm could one more do? :) It's much safer this way. And
    if we discover merging into sapi/cgi really makes sense - at least we'd have
    code that already works with php, plays by php rules, etc. so it'd be much
    easier and safer.
    From outside this also seems like the correct route to take. A much
    better place from which to re-work any common codes.

    In regards to libevent library, it's probably enough discussions for
    now as we all seem in agreement. We shall see about getting libevent
    moved out from the fpm-0.6.4 sources and changed over to a libtool
    dependancy. I guess it can't be particularly very much work to solve.
    I would actually suggest to make a branch in the PHP SVN so that you can
    make the modifications in there and make things work. From there on we
    could then merge it into PHP proper. The PHP configure and build things
    make quite a few assumptions and I think you'll run into some issues at
    some point. It'll also allow us to peek and offer some assistence while
    things are being worked on.

    regards,
    Derick
  • Dreamcat four at Sep 9, 2009 at 10:36 am

    On Wed, Sep 9, 2009 at 10:58 AM, Derick Rethanswrote:
    I would actually suggest to make a branch in the PHP SVN so that you can
    make the modifications in there and make things work. From there on we
    Thank you. Don't have svn-commit access so kindda need to get that.
    could then merge it into PHP proper. The PHP configure and build things
    make quite a few assumptions and I think you'll run into some issues at
    some point. It'll also allow us to peek and offer some assistence while
    things are being worked on.
    Won't be altering php configure / acinclude.m4 until it's sitting in a
    svn branch.

    Whats best to start on initially: 5.2.X, 5.3.X or trunk/6.0 ?
    I'm okay with 5.3 but open to suggestions.


    Best regards,

    dreamcat4
    dreamcat4@gmail.com
  • Derick Rethans at Sep 9, 2009 at 10:44 am

    On Wed, 9 Sep 2009, dreamcat four wrote:

    On Wed, Sep 9, 2009 at 10:58 AM, Derick Rethanswrote:
    I would actually suggest to make a branch in the PHP SVN so that you
    can make the modifications in there and make things work. From there
    on we
    Thank you. Don't have svn-commit access so kindda need to get that.
    Yeah, that can be arranged of course: http://www.php.net/svn-php.php I
    can create a branch for you once you have an account.
    could then merge it into PHP proper. The PHP configure and build
    things make quite a few assumptions and I think you'll run into some
    issues at some point. It'll also allow us to peek and offer some
    assistence while things are being worked on.
    Won't be altering php configure / acinclude.m4 until it's sitting in a
    svn branch.

    Whats best to start on initially: 5.2.X, 5.3.X or trunk/6.0 ?
    I'm okay with 5.3 but open to suggestions.
    New features only go into trunk usually... but if this is totally stand
    alone I don't mind having it in 5.3 either (that's my own personal
    opinion though).

    regards,
    Derick
  • Stanislav Malyshev at Sep 9, 2009 at 9:08 pm
    Hi!
    New features only go into trunk usually... but if this is totally stand
    alone I don't mind having it in 5.3 either (that's my own personal
    opinion though).
    I think if it goes to branch and is isolated as SAPI should be there
    shouldn't be a problem to merge it to 5.3 when it's ready.

    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Dreamcat four at Sep 18, 2009 at 12:54 pm
    Hi !

    Please find enclosed the most recent fpm sapi, version 0.6.5,
    including "config.m4" configuration file.
    To compile it requires (1) external library, libevent.

    Just apply the patch, and uncomment the appropriate line depending
    whether php 5.2.X or 5.3.X.

    cd php-src
    patch -p1 < ../fpm.patch

    sapi/fpm/cgi/cgi_main.c:
    case 'e': /* enable extended info output */
    CG(extended_info) = 1; /* 5_2 */
    /* CG(compiler_options) |=
    ZEND_COMPILE_EXTENDED_INFO; */ /* 5_3 */
    break;


    Best regards,

    dreamcat4
    dreamcat4@gmail.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedSep 8, '09 at 11:52p
activeSep 18, '09 at 12:54p
posts22
users8
websitephp.net

People

Translate

site design / logo © 2022 Grokbase