Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45730
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain tekrat.com from 208.43.138.18 cause and error)
Message-ID: <4AD243A7.4020506@tekrat.com>
Date: Sun, 11 Oct 2009 13:44:23 -0700
User-Agent: Postbox 1.0.1 (Macintosh/2009100516)
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: PHP Internals List <internals@lists.php.net>
References: <4AD191B7.6080803@tekrat.com> <fe05d1540910110601v109a8bcai4bd1f56b155c8f68@mail.gmail.com>
In-Reply-To: <fe05d1540910110601v109a8bcai4bd1f56b155c8f68@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: php_config --extra_includes
From: shire@tekrat.com (shire)


Heya,

Pierre Joye wrote:
> hi!
>
> On Sun, Oct 11, 2009 at 10:05 AM, shire<shire@tekrat.com>  wrote:
>> Currently we have an open bug #16809
>> (http://pecl.php.net/bugs/bug.php?id=16809&edit=1) in APC where we're unable
>> to find the pcre.h header file as it's not in our include path when a user
>> compiles PHP with the --enable-pcre=<some include path>.  This is because
>> the include path the user provides isn't made available in INCLUDES in the
>> extension (APC) when compiled as a shared library using phpize.
>>
>> I've come up with the following solution, but want feedback/other options
>> before I commit.  Essentially I've made use of the EXTRA_INCLUDES that's
>> included in INCLUDES, but not really used much of anywhere AFAIK.  I've also
>> added the autoconf macro PHP_ADD_EXTRA_INCLUDE that mirrors the
>> PHP_ADD_INCLUDE behavior, as well as the --extra_includes option to
>> php-config.  This way extensions can provide additional include paths that
>> they depend on for extensions that may in-turn be dependent on their header
>> files.
>>
>> http://tekrat.com/downloads/bits/extra_includes.php5.3.patch
>
> Would it be not more correct to test if the bundled pcre is used or
> not. And detect the pcre header if the system pcre is used?


We can definitely check to see if PCRE is bundled or not, but how do we detect the exact path of the pcre.h file that was used?  (we could also have multiple pcre.h files on the same system), so it seems we need to store this somewhere in the PHP configuration that the shared extension can pull from.  My thinking here was that just making it part of the existing INCLUDE path was easiest, we could probably make this some sort of macro that the extension has to explicitly call to get this path included as well.  Perhaps that's more ideal so we don't get a bunch of extra include paths we don't actually need for other extensions?

I'm not sure I follow the openssl/libxml examples entirely, as this case would be us depending on having a way for an extension like APC to get the location of openssl includes/lib paths.  Do we have that scenario somewhere?

Thanks!

-shire