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.

Attachment: pgpQZnM5rGfDS.pgp
Description: PGP signature

Reply via email to