Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45731
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.155 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=EAa8u5H0cZKmCZA2F4GvcMSZeWzKV0uiUeTbY/B5yGH/6lt0y9xNNKo1LDTHpUrZbL
         hmT129tTPpCHfDOM0+DK02rgO3MglwUrohV/ExUwl8kqrHappWpdALyYA9aheud+49+H
         bQB1mfCAs7rI8qEF/fv5Yc1wUaL4b5YNbl0JA=
MIME-Version: 1.0
In-Reply-To: <4AD243A7.4020506@tekrat.com>
References: <4AD191B7.6080803@tekrat.com>
	 <fe05d1540910110601v109a8bcai4bd1f56b155c8f68@mail.gmail.com>
	 <4AD243A7.4020506@tekrat.com>
Date: Sun, 11 Oct 2009 22:59:05 +0200
Message-ID: <fe05d1540910111359g74cb805alcc4169b285288d69@mail.gmail.com>
To: shire <shire@tekrat.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: php_config --extra_includes
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Sun, Oct 11, 2009 at 10:44 PM, shire <shire@tekrat.com> wrote:

> 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? =A0(we could also=
 have
> multiple pcre.h files on the same system), so it seems we need to store t=
his
> somewhere in the PHP configuration that the shared extension can pull fro=
m.

If the flag for the bundled PCRE is set, the include path should be
set to php's include directory, or to the system pcre if not.

The problem is when the system PCRE is installed in the default prefix
just like any other libs and php was built with the bundled PCRE. In
this case you can just hope that php's include is first in the list,
but this configuration is a call for troubles and should not be
supported (we bogus'ed some bugs about that afair).

> =A0My 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. =A0Pe=
rhaps
> 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 th=
e
> location of openssl includes/lib paths. =A0Do we have that scenario somew=
here?

A PHP_SETUP_PCRE could do all the jobs for you. Then you would only
have to use something like:

  PHP_SETUP_PCRE(APC_SHARED_LIBADD,
  [
    AC_DEFINE(HAVE_PCRE_EXT,1,[ ])
  ], [
    AC_MSG_ERROR([OpenSSL check failed. Please check config.log for
more information.])
  ])

By the way, given that PCRE is enabled by default in 5.3+ (maybe in
5.2 too, I don't rememer :), I don't see it as a dependency. Maybe APC
could add an extension depency and use ext/pcre's exposed API (which
implements the cache as well).

Cheers,
--
Pierre

http://blog.thepimp.net | http://www.libgd.org