Antony Dovgal wrote: > What's wrong with PHAR ? > Why do you need another tool, which does pretty much the same?
Nothing's wrong with PHAR... I am sorry but my question's purpose was not to discuss about why I am building such a tool. And the change I am suggesting would also benefit PHAR (if PHAR could set 'phar://' in the include path, it would become possible to keep relative paths in include statements). I could explain, of course, why phar doesn't fit my needs, but I would prefer to keep this topic on the PHP core aspect. The reason I don't start a topic to talk about the tool I am writing is that the documentation is not ready yet. And I want to write at least the user's guide before asking for your comments. The doc contains a section explaining why I chose not to use or enhance PHAR... But... OK, to resume, the main problem I met with PHAR was that I wanted to package libraries and not a whole application. I wanted to keep the tools and libraries I was calling from my main program as single package files. And PHAR cannot do that. I have several main scripts, which use several libraries, and I don't want to rebuild everything each time I change anything in a library. Think of it as static vs dynamic linking. So, I needed a tool which could 'mount' several package files on the same stream wrapper. It could have been done with phar but I would have had to change the URL syntax to include a 'mount point' as first element of the path. And, if I had chosen this way, I would still be discussing about compatibility problems... So, I created a new tool. If you want to read the documentation (just chapter heads at this time), please have a look at http://www.tekwire.net/redir.php/phk Regards Francois -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
