Re: Re: Phpdocumentor memory usage

The problem comes about when one looks at the number of packages that must be installed before phpDocumentor will work. Smarty must be installed inside the phpDocumentor location, and must be version 2.4.x, as later versions are different. The same is true of HTML_TreeMenu. The constructor format changed, breaking BC. A user would have to not only install the package separately, but know which version. Installing phpDocumentor would require: -download, install phpDocumentor -download, install Smarty inside phpDocumentor, or modify every file that includes Smarty to point to Smarty (no standard install location) -upgrade PHP to PHP 4.3.0+ -download, install PEAR (we all know how impossibly difficult this is for most windows users currently) -download, install HTML_TreeMenu, make sure it is the correct version -download, install Cpdf from sourceforge, install it in the same directory as the PDF Converter Some people are willing to do all of this work, others are not. Not only this, Cpdf has some bugs that are fixed in the bundled version, so it gets very complex to subclass. This complexity of install is why phpDocumentor doesn't depend on the xslt functions, as installing xslt support on windows is a huge ordeal. In any case, I'd love some ideas on how to handle the non-PEAR package dependencies until things stabilize in a year or two. Greg Roman Neuhauser wrote:

# neuhauser@bellavista.cz / 2003-03-21 08:30:20 +0100:

# greg@chiaraquartet.net / 2003-03-20 19:37:00 -0500:

The only thing I want to ensure is that phpDocumentor doesn't depend on external entities to work, as much as possible, so that it is a run-out-of-the-box tool. As PEAR matures, I want to make it an option to depend on the PEAR classes that are used, like HTML_TreeMenu, but not a requirement. Same with any non-standard C extensions. So, if phpDocumentor uses DB_DataObjects, for example, I'll include the source for DB_DataObjects bundled as an option, separate from PEAR, but also have a release available that depends on PEAR being installed. Does this strike everyone as reasonable?

Not really. If the library is used without changes, it shouldn't be bundled.

And if it's modified it should be subclassed and then there's no need to bundle the parent either.