Re: PL/perl should fail on configure, not make

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> ... The core issue here is that header files and link-time
> library files are in different packages that can be installed
> separately. Any other library were this choice was made would create
> the same issue. The fault is that configure checks only one thing and
> assumes two.

It's complete folly to imagine that configure checks all and exactly the
things that we require to build. In fact, I'd argue that a majority of
what it does is inference or approximation of some sort. For an example
we need look no further than the AC_CHECK_FUNC logic, which is not
actually testing that a function-like symbol is available to be called.
If autoconf were trying to be exact, its scripts would be many times
larger and slower, but not many times more useful. Similarly, there is
no very good reason for our configure code to spend cycles testing for
cases that we don't expect to see in the field.

In the case at hand, up to now we have been checking that you have
ExtUtils::MakeMaker and assuming that if you do, you have perl headers
and libperl.so. The first of these inferences seems valid enough to me,
as the presence of MakeMaker suggests that you have facilities for
building Perl extensions. As for the second, it's pretty common to
suppose that headers and .so symlinks are packaged together.

I continue to assert that Debian's choices here are less than sane.

But in any case, the link test for libperl.so is going to go away again
unless someone can explain how to make it work on Gentoo.

regards, tom lane