Re: [binarycloud-dev] ext/pear question

[Alex B. <en...@tu...>]

> 
> alex,
> i'm seeing that you've added the entire PEAR tree under ext/.  my
> impression of this BC/PEAR convergence was that you were just going to
> add the PEAR libraries that BC used, not the entire PEAR tree.  it just
> seems sticky doing it this way because of version conflicts, and the
> hassles of keeping the entire tree up to date; not to mention simple
> scattered file duplication.

Ah, for a couple reasons:
    -yes, I could include only the files that bc/core needs, but after
thinking about that I don't like it. here's why:

pear (for the moment) is released with each php version, as one big glob. it
requires a make, etc and at the moment (as far as I can tell) is basically
uninstallable from cvs.

Point at which pear gains package installation capabilities, I will instead
distribute a script which automatically downloads and installs the necessary
pear packages.

For prerelease development, I prefer just having the whole pear tree in cvs
for convenience. I do not expect r2/final to be distributed with the entire
pear tree, that would unnecessarily bloat the tarball. I think by the time
r2/final is out, a functional (if basic) package installation script(s) will
be ready for pear.

> it would seem to me that this would be best handled one of two ways.  if
> the stock PEAR modules (stock being the keyword) are to be used by BC, a
> simple importing of that PEAR library would suffice.  if the needed PEAR
> module needed additional tweaking to comply better with BC needs, then
> it would be added to ext/pear; but only if it was a "hacked" version for
> BC use.

ah, nope.

pear libs must reside within binarycloud/ext/ so they are part of the make
process, and can be included with import statements.

also, this is very important: I have no intention of making _any_ even
_minor_ modifications to pear libs. I don't want to get into that nightmare.
I'd far prefer to suggest and implement functionality in existing pear libs,
and contribute new libs that we create which can be used outside of the
system.

best,

_alex




> hope this made some sense --
> jason
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 


--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093