On Wed, Dec 05, 2012 at 03:08:24PM -0500, Rafael Schloming wrote: > > Okay, then a developer has to explicitly override the INI directory each > > time. For the EXT and INCLUDE directories it's easy to do what we're > > doing in Perl now to override the prefix. That feels a little clumsy to > > me since I don't really want to have to specify it each time I do a > > build. > > I'm not sure I follow you. These are all configured variables. You only > ever have to set any of them once.
To keep things from lingering, each time I do a build I go into my OOT build directory and do: rm -rf * && cmake ../proton-c I don't want to have to specify the PHP_INI_DIR when I do the above. I suppose I could have an alias defined for it (maybe have config.sh source a separate, non-versioned file containing developer aliases?). But that could very well gum up the plumbing. :) > The only question is how to default them. The php binding defaults them by > interrogating the php install and supplying the system configured > extensions directory and so forth. WIth this default the bindings will all > get loaded automatically. On the other hand if you default them by > replacing the prefix, then anytime you use an install prefix that is > different from php's install prefix, the bindings will wind up in a > location that isn't automatically loaded, and so nothing will work unless > you hack the php install to look in whatever non standard location you've > picked, and it seems like if you're going to do this hacking anyway you can > just explicitly configure exactly where you want the various components of > the bindings to be installed. I suppose my usage isn't quite the same as what Andrew mentioned. For me, I don't install to non-standard places, so my above scenario won't be affected. IOW, I don't do "make install" and run from those installed pieces and instead run against things in my CPROTON_BUILD directory. I guess for a developer who's doing as Andrew mentioned, they'll have to override PHP_INI_DIR when they install, which should be less frequent than my in-place builds. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Description: PGP signature