On Wed, Dec 5, 2012 at 4:38 PM, Darryl L. Pierce <dpie...@redhat.com> wrote:
> 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. :) > You may not have to. It's not necessary for building, only if you want to do a make install. 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. > So the main point of this stuff is to make proton easy to install for users. I'm all for making our lives as developers easier, but not at the expense of users, and I think not having the bindings behave as I've described will significantly complicates things for users. Imagine a system with python installed in /usr, and perl and php both installed in /usr/local. Say a user wants to install proton and the relevant bindings onto this system. If all the bindings default their location based on interrogating the installed interpreters, this is easy. The user can choose to install proton itself into either /usr or /usr/local, and all the bindings will just go into the right place. Now consider what happens if we automatically munge the prefix. There really isn't a good way to explain to a user how to install on this system. They either need to choose to put proton into /usr and munge their perl and php installs to look for extensions under /usr as well as /usr/local, or possibly somehow override undocumented variables in the cmake build to get the extension modules into the right place. I don't even know if this is possible as the overridden variables might well be munged. I think this scenario really points to two issues (1) the defaults really should be based on interrogation of the interpreters that the bindings are built against if we want a robust and simple README file, and (2) all the bindings should support proper manual overriding of the installed location of each binding. I believe (2) is only the case for the PHP binding currently, or at least it was the case before the php binding was modified to do the munging. Unless I'm missing something, I'd like to suggest we rollback that change and make the other bindings match the PHP behaviour of defaulting based on interrogation and providing proper configuration variables for manual override. I'm aware this might make certain developer scenarios mildly more onereous, but with manual overrides in place they should all be possible, and I believe the benefit for users is significant. --Rafael
