Some quick follow-ups to a few points of discussion ... On Tue, 28 May 2024 at 13:51, Greg Troxel <[email protected]> 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. _______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
