On Mon, Apr 28, 2014 at 4:55 PM, Gordon Sim <[email protected]> wrote:

> On 04/28/2014 09:30 PM, Justin Ross wrote:
>
>> On Mon, Apr 28, 2014 at 4:27 PM, Gordon Sim <[email protected]> wrote:
>>
>>> Can SYSINSTALL_BINDINGS=ON not be automatically inferred if no
>>>>> CMAKE_INSTALL_PREFIX is specified? Or does CMAKE_INSTALL_PREFIX always
>>>>> have
>>>>> a value, even if not set explicitly?
>>>>>
>>>>>
>>>>>   That would overwrite OS-reserved file locations.
>>>>>
>>>>
>>>>
>>> That's what make install (without an explicit prefix) always does, isn't
>>> it?
>>>
>>> If I don't specify a prefix, I expect things to be installed into the
>>> system wide default locations for whatever it is. If I specify a prefix,
>>> I
>>> expect to to be relative to that and expect to have to set various path
>>> variables to locate 'my' install.
>>>
>>>
>>>  No, the default prefix is typically /usr/local, and indeed /usr/local is
>> set aside for this use.  For instance, setup.py install by default
>> installs
>> with the prefix /usr/local on unix machines.
>>
>
> Yes, I wasn't suggesting changing the default.
>
> So are you saying that SYSINSTALL_BINDINGS doesn't use the 'default', but
> overrides that? If so then I agree with Fraser that the language in the
> warning is confusing. (Since it sounds like the 'non-standard 'approach is
> used by default unless the 'standard' one is explicitly selected.


There are differing ideas about what the "default" means.

SYSINSTALL_BINDINGS=ON means "query the interpreter for its standard
library location".  "The interpreter" is whatever happens to be on the path
at the time the query is performed.  The queried location is *not* modified
for any prefix value you may have specified.

If you do this on a fresh Fedora install using Python, the query returns
something like /usr/lib64/python2.7/site-packages/.  As you know, this is
an OS-reserved location.  If you "sudo make install" to this location, you
can easily overwrite packager-installed files.

When I discovered this behavior was turned on by default (and had spread to
the cpp tree), I complained vociferously.  Rafi is eager to keep this
behavior (me, not so much).  I'm most concerned that it not be the thing
that happens by default.

The "default", IMO, should be what I think you're referring to: the
standard library path for a given language, but one modified for a safe
prefix reserved for locally installed modules.  In the case of Python, this
would be /usr/local/lib64/python2.7/site-packages/ on my system.

Finally, I agree with you and Fraser about the warning.  I think it makes
it look like something weird is happening, but really we're hewing closer
to what I consider normal behavior.

Reply via email to