Folks,
Well, I got this extension_dir logic work completed based on my PHP
5.2.5 CVS copy of PHP. The feature allows your to set the extension_dir
for multiple paths. This is what I had so far in PHP.INI-DIST/RECOMMENDED.
;---------------------------------------------------------------------
; Directory locations (paths) in which the loadable extensions (modules)
; reside. To add multiple paths, separate paths using ":" (UNIX) for
; ";" (Windows) character. Examples:
;
; UNIX: extension_dir = "/path1:/path2"
; Windows: extension_dir = "\path1;\path2"
;
; Note: Explicit FQFN (Fully Qualified File Name) extension loading
;
: Extensions with explicit FQFN can be used to skip the
; extension search in the extension_dir path(s).
; i.e. extension = c:\serverapp\bin\php_wildcat.dll
;
;---------------------------------------------------------------------
extension_dir = "./ext"
The source code change was done on the ext\standard\dl.c file.
I was about to create the patches for the current PHP52, PHP53 and PHP6
snapshots when I noticed there was a change in PHP53 that was done that
allows for explicit FQFN extension= loading.
<side beef>
I don't know if this was a result of someone lurking the list and
decided to go ahead and do this after reading the related recent thread
for the multi-path extension_dir proposal, which is fine, but if they
did go about this after seeing the thread, a simple courtesy to post a
note of their intention would of been appreciated. Things like this
waste people's time.
</side beef>
In any case, to see if there was any other stuff related to this, I
checked the bug database and found two related past feature request
related to this:
Bug # 22587 (Mar 2003) extension_path feature
Bug # 41310 (May 2007) make extension_dir optional and use absolute
paths in "extension = ..."
#22587 is pretty much what I am satisfying.
#41310 was interesting so I wanted to see if this was possible now.
Using my 5.2.5 release installation (which would be the same logic as
5.2.6), I tested the following PHP.INI option:
extension_dir="./ext"
extension_dir="../../php_wildcat.dll"
and of course, the source code logic show this as well.
But the PHP53 FQFN change now breaks this.
The PHP53 change allow for extension= module loading if the filename has
a directory separator, but not supported for temporary loading via a PHP
script DL() function.
extension=c:\path\php_extension.dll <== works under PHP53 only
dl("c:\path\php_extension.dll") <== never supported.
I personally think PHP53 change is more correct, but that depends on
your point of view. Should the filename loading be off the ROOT path
for the PROCESS or off the extension_dir path was what the 5.2 logic.
It also depends on what the file name is:
FQFN means a complete path (not relative)
There could be a change where if the file name has relative folder
reference (../) then it could use the extension_dir as the root as it
was supported in PHP52. If its FQFN, then its a explicit load.
In all, this is what I think:
1) PHP53 breaks PHP52 logic. Although "more correct", its breaks
working code so we need to do something there.
2) Consider using a new extension_path to override extension_dir
thereby keeping extension_dir PHP52 intact and only apply the
multiple path search to the new extension_path, if defined.
3) Continue with the current patch I am doing with extension_dir
and if a extension= has a relative path, apply this only to
the FIRST path defined in extension_dir. For example:
extension_dir="./ext;c:/wildcat;c:/other"
extension=php_zip.dll
extension=php_wildcat.dll
extension=../php_extension2.dll
extension=c:\somewhere\php_extension3.dll
php_zip.dll has no folder information, so its found its stock ./ext folder.
php_wildcat.dll has no folder information, its not in ./ext so the
additional paths are checked and its found in c:/wildcat
php_extension2.dll has a relative location, so to continue with PHP52
expectations, it will only use the first path "./ext" as its root.
php_extension3.dll has a FQFN so its explicitly loaded with the FQFN.
Comment? What path do you think its the best way?
Again, although PHP53 change logic seems to be more correct, IMO, that
is would be so if PHP was new and there was no working code out there.
But as it was done now, it does break the PHP52 logic.
--
Hector Santos
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
