You're not going to want people to check out svn versions of the PHP
code, right? You'll want to have some kind of packaging system in
placed to do real releases at some point.
So I suggest that a small 'build' step might be appropriate for the
PHP code too. This is where you can do some of the heavy operations
that only need doing once. For development one can execute a single
"prep" step that pulls in external dependencies.
If you try to run the PHP code straight from svn with this 'prep' step
then an appropriate error message can be displayed.
One interesting example of how this might work is the 'cacti' PHP
package (which has explicit checks in place for compatible data
schemas) or Movable Type, which has a build procedure that pulls in
external dependencies and requires the user to customize their config,
or else sensible error messages are displayed.
On Aug 15, 2008, at 1:48 PM, Chris Chabot wrote:
Not always build in by default, through a quick sample of my PHP
environments it's enabled on RedHat Enterprise / Fedora Linux, but
it's not enabled on Mac OS X (leopard) and neither is it on the Open
Solaris servers.
So that would be possible to use, but would limit the environments
on which it can be deployed by another couple of %'s,
Or, how about i manually unzip the jar, copy the .js file to the
shindig/features/foo dir, and svn commit and repeat this when ever
people ask for it ? :)
-- Chris
On Aug 15, 2008, at 10:36 PM, Brian Eaton wrote:
On Fri, Aug 15, 2008 at 1:33 PM, Chris Chabot <[EMAIL PROTECTED]>
wrote:
I'm sorry to have to inform you that PHP is an environment that
does not
require, nor has a 'build time', you copy the *.php file to a web
root,
point your browser at it, and ... that's it... there is no step 3.
http://us3.php.net/zip?
Paul Lindner
[EMAIL PROTECTED]
