Bug#897149: Package erroneously expects googletest headers in /usr/include

2018-05-01 Thread Steve M. Robbins
On Sun, Apr 29, 2018 at 01:36:08PM +0200, David Kalnischkies wrote:

> Not really knowledgeable enough about cmake through to know if that is
> the best we can do ??? it looks kinda ugly/dirty.

Your patch looks fine to me.  A slight improvement below avoids
repeating the /usr/src path.

 
> We could also switch to using the prebuilt library in libgtest-dev; it
> is happily picked up if available (which is why I didn't notice before).
> Not sure how the version constraints need to look to deal sanely with
> the constant name-changing of gtests packaging through???

Yeah, sorry about that.  If you are concerned with building in, say,
stable then be aware that the prebuilt library does not exist in
stable.  So using the sources would be a better option.


Here's a revised patch.

diff -u -r apt-1.6.1/test/libapt/CMakeLists.txt 
apt-fix/test/libapt/CMakeLists.txt
--- apt-1.6.1/test/libapt/CMakeLists.txt2018-04-20 05:08:18.0 
-0500
+++ apt-fix/test/libapt/CMakeLists.txt  2018-05-01 19:23:40.251529593 -0500
@@ -16,7 +16,7 @@
set(GTEST_LIBRARIES "-lgtest")
set(GTEST_DEPENDENCIES "gtest")
set(GTEST_FOUND TRUE)
-   find_path(GTEST_INCLUDE_DIRS NAMES gtest/gtest.h)
+   find_path(GTEST_INCLUDE_DIRS NAMES gtest/gtest.h PATHS 
${GTEST_ROOT}/include)
 
message(STATUS "Found GTest at ${GTEST_ROOT}, headers at 
${GTEST_INCLUDE_DIRS}")
 endif()


-Steve


signature.asc
Description: PGP signature


Bug#897149: Package erroneously expects googletest headers in /usr/include

2018-04-29 Thread David Kalnischkies
On Sat, Apr 28, 2018 at 11:20:46PM -0500, Steve M. Robbins wrote:
> Your package relies on this behaviour and now fails to build since
> googletest version 1.8.0-9 no longer installs the duplicate header
> files.

*sigh* Seems like we can solve this by:

diff --git a/test/libapt/CMakeLists.txt b/test/libapt/CMakeLists.txt
index 86c0b28b5..c770d57bb 100644
--- a/test/libapt/CMakeLists.txt
+++ b/test/libapt/CMakeLists.txt
@@ -16,7 +16,7 @@ if(NOT GTEST_FOUND AND EXISTS ${GTEST_ROOT})
set(GTEST_LIBRARIES "-lgtest")
set(GTEST_DEPENDENCIES "gtest")
set(GTEST_FOUND TRUE)
-   find_path(GTEST_INCLUDE_DIRS NAMES gtest/gtest.h)
+   find_path(GTEST_INCLUDE_DIRS NAMES gtest/gtest.h PATHS 
/usr/src/googletest/googletest/include)

message(STATUS "Found GTest at ${GTEST_ROOT}, headers at 
${GTEST_INCLUDE_DIRS}")
 endif()


Not really knowledgeable enough about cmake through to know if that is
the best we can do – it looks kinda ugly/dirty.


We could also switch to using the prebuilt library in libgtest-dev; it
is happily picked up if available (which is why I didn't notice before).
Not sure how the version constraints need to look to deal sanely with
the constant name-changing of gtests packaging through…

(or well, we probably need to end up with a mix of all that to keep
working everywhere, so… no patch, just a hint for others looking into
it as I was a bit surprised it worked for me locally…).


Best regards

David Kalnischkies


signature.asc
Description: PGP signature


Bug#897149: Package erroneously expects googletest headers in /usr/include

2018-04-28 Thread Steve M. Robbins
Package: apt
Version: 1.6.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

control: block 897104 by -1

Hi,

The googletest package provides full sources -- including header files
-- in /usr/src/googletest.  Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.

Your package relies on this behaviour and now fails to build since
googletest version 1.8.0-9 no longer installs the duplicate header
files.

I can suggest three alternative approaches to fix this.

1. Modify the build to look for headers in /usr/src/googletest.

2. Change to using pre-build libraries, in which case you would switch
build-dependencies to libgtest-dev and libgmock-dev rather than using
googletest.

3. Add build-dependency on libgtest-dev to ensure the headers are
located in /usr/include as before.  If gmock is used, then add a
dependency on libgmock-dev as well.


-Steve