[PROJ] PROJ 9.4.1RC1 & PROJ-data 1.18RC1

[Mike Taves]

Some quick follow-ups to a few points of discussion ...

On Tue, 28 May 2024 at 13:51, Greg Troxel <gdt at lexort.com> wrote:
> > The behaviour should disable tests if the minimum GTest is not
> > available, showing non-fatal error messages. It should allow it to be
> > built, without test capabilities.
>
> Hmm, well that is not what happened to me.  Makes sense that it is the
> plan.  I'll dig in.

This isn't the current behavior, I'm just stating the ideal outcome.
I'll need to replicate the scenario then create a fix to make the
ideal behavior.

> > Is there a general consensus if "tests should not use the network at
> > build time" is a bug or not?
>  ... <snip>
>   it is a bug to try to use the network at all during the configure,
>   build, or install phases, period.
> ... <snip>

Thanks for providing a packagers perspective! The reliance on network
availability for fulfilling GTest requirements isn't new and I didn't
originally add it. As mentioned previously, this can be avoided by
providing a soon-to-be-documented "googletest" test requirement.

As for generally changing network dependency at configure/build/test
time, I'm fine with these suggestions to turn them off by default.
Unmet build dependencies could show a CMake error and suggestion how
to enable them. However, these changes may need further consensus (I'm
a contributor, not part of PSC) and will probably need to wait for the
next major release.

> > Are you able to re-test with googletest installed?
>
> Yes.  It was just adding to the Makefile to depend on it:

Progress.

> I know there are perhaps some cmake RPATH issues, where pkgsrc trying to
> control the build may be at cross purposes to what a package is trying
> to do.  This used to work well with autoconf/libtool.
>
> Do you believe that the tests link against and use the just-built
> libraries in the build tree?  I think they should.  If that's generally
> the case I'll sort this into a pkgsrc-cmake-support bug for now.

RPATH stuff confuses everyone, myself included. CMake does a few
tricks with this respect. I believe the RUNPATH is kept consistent
with the local build tree (for testing) and then changed to the
install target:
https://github.com/OSGeo/PROJ/blob/3b7a6a9b2e5ca9441cd589f552d64a9ec196678f/src/apps/CMakeLists.txt#L36

So it's a bit of a surprise that a different libproj somehow slips
into the test. If possible, see the RUNPATH from readelf -d bin/proj
It should be an absolute path to the lib dir in the build tree, and
not just "libproj.so.x.y" from LD_LIBRARY_PATH.