On 01/14/2018 10:09 PM, Hal Murray wrote:
>> 1) Does configure bail if installing the python libs might not work? No.
>
>> I think #1 always has to be no. Otherwise, you'll break tons of working
>> setups, including but not limited to package builds.
>
> Could you please say more.
>
> I'm assuming that PYTHONPATH or xxx.pth would fix the problem and bailing at
> configure time just means you have to fix it pre configure/build, similar to
> setting things up by installing bison and various xxx-devel packages.
Let's take my Ubuntu system for example.
If I run the default:
./waf configure
that is equivalent to:
./waf configure --prefix=/usr/local
which, on Debian derivatives using, for example, Python 2.7 is
equivalent to:
./waf configure --prefix=/usr/local \
--pythondir=/usr/local/lib/python2.7/dist-packages \
--pythonarchdir=/usr/local/lib/python2.7/dist-packages
(Note that site-packages becoming dist-packages is a Debian-ism.)
Assuming this is a newly-installed system,
/usr/local/lib/python2.7/dist-packages does not exist. Since it does not
exist, it does not show up in sys.path.
If you follow through with the ./waf install, it will create
/usr/local/lib/python2.7/ntp and put the ntp module files there.
Since /usr/local/lib/python2.7 then exists, it will show up in sys.path
on subsequent runs of python, and everything will work.
If you make ./waf configure bail, you break me needlessly--and everyone
on Debian derivatives and any other distro that includes /usr/local in
sys.path by default.
Warning is fine, as I can ignore a warning.
Setting PYTHONPATH or creating a .pth file is unnecessary. Why should I
have to do that when it would have worked fine without it?
Also, while setting non-existent directories in PYTHONPATH *does* cause
them to show up in sys.path, setting non-existent directories in a .pth
file does *not* cause them to show up in sys.path.
See also the scenario below.
>> If someone is writing a post-install warning, you might want to omit it (or
>> soften the language) if --destdir is set.
>
> I was assuming that destdir is only used to put stuff off to the side during
> packaging. The will-it-work check should be concerned with the final
> destination so a configure time check based on prefix and pythondir seems
> right to me.
>
> Is there another use case for destdir?
No, that's the case I have in mind.
Consider the same case as above, but this time, we're doing an
install-time check instead of a configure-time check. To be clear, there
is no --destdir yet. I run ./waf install. It creates
/usr/local/lib/python2.7. Then it runs the "will-it-work check". Since
the directory now exists, the check *passes*. That's why post-install is
better than post-configure.
Let's add --destdir to the mix. I run `./waf install --destdir=tmp`. It
creates ./tmp/usr/local/lib/python2.7. If it runs the "will-it-work
check", that will look at sys.path for /usr/local/lib/python2.7. Since
that directory still does not exist (we created one under ./tmp, not /),
the check fails.
If you're going to suggest looking in $DESTDIR, that's just wrong. Even
if you did, it still wouldn't work, as ./tmp/usr/local/lib/python2.7 is
certainly not in the default sys.path.
The will-it-work check will have a lot of false positives in the
--destdir case. That's why I suggest omitting or softening the warning.
--
Richard
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
