Make sure vcpkg_test_cmake uses the correct generator

[tarcila]

Otherwise, on Windows, it will default to x86 based generator that will
fail finding x64 builds. For instance, when building for x64-windows:

CMake Error at CMakeLists.txt:4 (find_package):
Could not find a configuration file for package "CapnProto" that is
compatible with requested version "".

The following configuration files were considered but not accepted:

vcpkg/packages/capnproto_x64-windows/share/capnproto/CapnProtoConfig.cmake, version: 0.7.0 (64bit)

[Neumann-A]

Minor thing:
${_VCPKG_CMAKE_GENERATOR} might not be set.

Changes are similar to:
4cfca10
and
be85bc5

except that you allow to manually define a generator.

[tarcila]

Indeed, that's why the content of GENERATOR is tested later on.
I'll update the comment to make this more explicit.

[vicroms]

Quote from a discussion about this with ras0219:

We should always use ninja here (and skip it for 32-bit hosts). There's no reason to use the MSBuild generator, nor for it to be configurable. This is because all generators should work.

[tarcila]

Thanks for taking a look at this PR!

I agree with the latest part of the comment. But I don't get the rational for the very first part: why skip 32bits? and why ninja only?

The very first intent of my commit is, by using the same generator, that we target the same platform/architecture: the breakage on my side is that the package is generated for x64 but is searched for by an x86 generator.
But indeed, reusing the same generator might not be the way to go. Maybe just enforcing the architecture could be sufficient first step (I don't know if ninja generator supports -A flag).

Note that in a general case, it seems to me that find_package logic will be mostly independent of the generator used (when try_compile/link/run are not used at least).

[Neumann-A]

Would be nice if targets could also be tested

[vicroms]

Hi @tarcila

Thanks for your contribution!

I'll run a test against all packages, as it looks like this PR slightly changes the default behavior of calling vcpkg_test_cmake(PACKAGE_NAME <name>).

Our vcpkg_test_cmake() function has been working improperly for a while.

vcpkg_test_cmake() aims to test CMake integration as it would be consumed by a vcpkg user. but the design is inherently flawed and doesn't reflect a real-world usage scenario. And that's the reason why we don't check or encourage its use.

We are aware of the design flaws in it and we are planning on designing a better CMake integration test mechanism in the future.

[tarcila]

I'll run a test against all packages, as it looks like this PR slightly changes the default behavior of calling vcpkg_test_cmake(PACKAGE_NAME <name>).

I do confirm that the default behavior is changed when the package is generated using vcpkg_configure_cmake(). The rest should behave the same.
I did test a few packages that try and rely on vcpkg_test_cmake(), without regression, but indeed, I am not able to build all the packages on all the architectures, so your help is more than welcome.

Our vcpkg_test_cmake() function has been working improperly for a while.

vcpkg_test_cmake() aims to test CMake integration as it would be consumed by a vcpkg user. but the design is inherently flawed and doesn't reflect a real-world usage scenario. And that's the reason why we don't check or encourage its use.

Noted. I'll drop vcpkg_test_cmake() support from my other PR waiting for a resolution for this problem.
Thanks for the update.

[vicroms]

Looks like a similar change sneaked its way throug in PR #5574

Can you solve the conflicts and add the changes to manually specify the generator?

[tarcila]

Sure, will do. Le ven. 15 mars 2019 à 17:40, Victor Romero <notifications@github.com> a écrit :

…

Looks like a similar change sneaked its way throug in PR #5574 <#5574> Can you solve the conflicts and add the changes to manually specify the generator? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIOFX3bQeu9Y0J7m1nyB8v-aBQ9S-z3ks5vXBNngaJpZM4bpNm6> .

[tarcila]

@vicroms I have rebased the PR on top of the latest master.

[vicroms]

Due to multiple issues with vcpkg_test_cmake() it has been disabled.

A new CMake integration test solution will be designed, but for the time being that's still in our backlog.
We'll take the input in this PR and several others into account when designing the new solution.