ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> php-dev
php-dev
Re: [PHP-DEV] Extension_Dir: Proposal to offer multi-directory DLL loading
by Stanislav Malyshev other posts by this author
May 12 2008 12:50PM messages near this date
Re: [PHP-DEV] Extension_Dir: Proposal to offer multi-directory DLL loading | Re: [PHP-DEV] Extension_Dir: Proposal to offer multi-directory DLL loading
Hi!

>  In PHP52, it allows only relative paths:

Right, but 5.2 is stable version so I don't see new features going 
there. Thus I think it's better to discuss 5.3 for new stuff, unless 
it's something so critical that it must be in 5.2.

>  But if you are single sourcing foo.dll, why would you want to have 
>  multiple copies floating around?  Thats partially the point there, more 
>  importantly non-php related foo.dll is in one location outside of PHP.

I don't need multiple copies. But I may want to keep it in the same 
directory the extension is - otherwise I'd have to add the directory to 
windows path, which add overhead to install. By keeping all the stuff in 
the same directory, it'd work out of the box.

>  Today, if an application server wish to implement PHP, it will need to 
>  add its PHP extensions into the single extension_dir location.

Either that or use full paths in php.ini, depending on how the server is 
structured.

>  For an application server that traditionally does not desire for its 
>  DLLs to be floating outside its controlled environment, PHP does not 
>  play well here.

Why? Just put all the stuff into that extension directory, if you talk 
about Windows. On Unix, .so resolution rules won't help here, but having 
extension path is not going to change anything.

>  The include_path resolves the script issues, but we don't have the same 
>  flexibility with DLLs.

I'm not sure what do you mean here. If you mean that PHP extensions use 
external DLLs, then you have two cases:
1. DLL is used only by PHP extension, nothing else uses it. Resolution: 
put it in the same directory PHP extensions are.
2. DLL is used by other stuff (external programs, etc.), not only PHP. 
Resolution: put it into separate library directory and add the directory 
in system PATH.

In both cases, I don't see how path for _extensions_ is helping you, 
unless all your application lives in the same directory and for some 
reason it's not possible to either add it to the path or use full pathes 
in php.ini extension= directives (but is possible in extension_dir 
directive).

>      a) copy our DLLS into PHP "extension_dir" folders,
>      b) copy them to a windows PATHed folder,

If it's external use DLLs, b) is the right way to go. It is regardless 
of the extension - if multiple parts of the application use same DLL, 
and they may reside in different directories, PATH is only way I can 
think of that makes it work.

>  - PER application multi-ini include support. Scattered material seem
>    to suggest this is possible, I have not seen how.

You can do it in 5.3 with "user ini files", but it's not documented yet, 
unfortunately. Hopefully, it will be soon.
-- 
Stanislav Malyshev, Zend Software Architect
stas@[...].com   http://www.zend.com/
(408)253-8829   MSN: stas@[...].com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Thread:
Hector Santos
Hector Santos
Stanislav Malyshev
Hector Santos
Stanislav Malyshev
Hector Santos
Stanislav Malyshev
Sean Finney
Hector Santos
Lars Strojny
Hector Santos
Hector Santos
Elizabeth M Smith
Hector Santos

Privacy Policy | Email Opt-out | Feedback | Syndication
© 2004 ActiveState, a division of Sophos All rights reserved