search

cucumber / cucumber-cpp

Support for writing Cucumber step definitions in C++
MIT License
309 stars 132 forks source link

CMake fails on "json_spirit.header" that is not in the export set. #193

Closed konserw closed 6 years ago

konserw commented 6 years ago

Summary

CMake fails with following error:

CMake Error: install(EXPORT "CucumberCpp" ...) includes target "cucumber-cpp-nomain" which requires target "json_spirit.header" that is not in the export set.
CMake Error: install(EXPORT "CucumberCpp" ...) includes target "cucumber-cpp" which requires target "json_spirit.header" that is not in the export set.

Expected Behavior

CMake pass without errors

Current Behavior

CMake fails with following error:

CMake Error: install(EXPORT "CucumberCpp" ...) includes target "cucumber-cpp-nomain" which requires target "json_spirit.header" that is not in the export set.
CMake Error: install(EXPORT "CucumberCpp" ...) includes target "cucumber-cpp" which requires target "json_spirit.header" that is not in the export set.

Possible Solution

Adding json_spirit.header to the export list? I don't have any experience on the topic.

Steps to Reproduce (for bugs)

  1. Clone cucumber-cpp master branch
  2. Run: 
    #!/bin/sh
rm -rf build
set -e #break script on non-zero exitcode from any command
set -x #display command being executed
export GMOCK_VER=1.8.0
export CXX=clang++
export C=clang
CTEST_OUTPUT_ON_FAILURE=ON
export CTEST_OUTPUT_ON_FAILURE
cmake -E make_directory build
cmake -E chdir build cmake \
-G Ninja \
-DCUKE_DISABLE_GTEST=off \
-DCUKE_DISABLE_E2E_TESTS=on \
${GMOCK_PATH:-"-DGMOCK_VER=${GMOCK_VER}"} \
${VALGRIND_TESTS:+"-DVALGRIND_TESTS=${VALGRIND_TESTS}"} \
..

    Results are the same with clang and gcc as compilers, so export C/CXX lines are not necessary

Context & Motivation

cucumber-cpp is just broken for me at the moment

Your Environment

I'm reproducing this bug on my personal PC:

[konserw@antegros cucumber-cpp]$ cmake --version cmake version 3.11.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

* Link to your project: no relevant project

I'm also reproducing this issue with semaphore-ci I'm experimenting with right now. It may be better for debugging as It is also based on Ubuntu Trusty like travis and is publicly available. But I'm using there my branch with some modifications: https://github.com/konserw/cucumber-cpp/tree/rebase-devel
Example of failed build on semaphore: https://semaphoreci.com/konserw/cucumber-cpp/branches/rebase-devel/builds/1
Versions used on semaphore:

cmake --version cmake version 3.5.1

CMake suite maintained and supported by Kitware (kitware.com/cmake).

gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


P.S. I'm not sure if this is related, but my with semaphore branch that didn't include install target CMake wasn't failing, but test that relied on json was failing:
https://semaphoreci.com/konserw/cucumber-cpp/branches/devel/builds/11

(::) failed steps (::)

No such file or directory @ rb_sysopen - /home/runner/cucumber-cpp/build/tmp/data_table.log (Errno::ENOENT) /home/runner/cucumber-cpp/features/step_definitions/cucumber_cpp_mappings.rb:199:in read' /home/runner/cucumber-cpp/features/step_definitions/cucumber_cpp_mappings.rb:199:inassert_data_table_equals_json' /home/runner/cucumber-cpp/features/cucumber-tck/step_definitions/cucumber_stepdefs.rb:278:in /^the data table is converted to the following:$/' /home/runner/cucumber-cpp/features/cucumber-tck/data_tables.feature:29:inThen the data table is converted to the following:'

Failing Scenarios: cucumber /home/runner/cucumber-cpp/features/cucumber-tck/data_tables.feature:21 # Scenario: a data table can be read as an array of hashes

67 scenarios (1 failed, 9 pending, 57 passed) 286 steps (1 failed, 24 skipped, 9 pending, 252 passed) 1m45.966s ninja: build stopped: subcommand failed.


Maybe we have some problem with those json headers itself, not the cmake file?
muggenhor commented 6 years ago

Do you maybe have a merge error?

Specifically is json_spirit.header listed as a PRIVATE dependency (in target_link_libraries) of the mentioned exported targets? Because I can only reproduce this by making that dependency PUBLIC instead.

konserw commented 6 years ago

@muggenhor - on my local machine I've got this issue using master branch from this repo - so no merging errors possible. And yes, it's listed under PRIVATE in src/CMakelists.txt

konserw commented 6 years ago

git bisect results:

2332cecc1b0ea40dafff1e29e4b3f73f0677678e is the first bad commit
commit 2332cecc1b0ea40dafff1e29e4b3f73f0677678e
Author: Giel van Schijndel <me@mortis.eu>
Date:   Wed May 23 11:51:48 2018 +0200

    Install exports and use GNUInstallDirs

    To support find_package(CucumberCpp) install(EXPORT). And use
    GNUInstallDirs instead of hardcoded installation paths.

:100644 100644 382afcc569a30fbab26f7693989abdeb45c4c514 01fff6016c6a67288e2cebf367ccbbb6e7d82169 M  CMakeLists.txt
:040000 040000 b7e60114b01f7c4c8eb5f072fbed71e418c17682 81d16f31595f9aa366695f06977e5afa433b1289 M  src
bisect run success
muggenhor commented 6 years ago

Hmm, seems this depends on whether we're building as a shared library or static. As a shared library this problem doesn't pop up, while as a static one it does.

I suspect this is caused by CMake's special behavior for handling PRIVATE dependencies transitively for static libraries. And if that's the case it's definitely wrong in this case (because we're depending on an INTERFACE library, the (non-linker) properties of which don't propagate when used PRIVATEly). Unfortunately that doesn't help us right now.

Can you check whether this commit helps you? f26bbadc

konserw commented 6 years ago

Yes it helps! So I think we need to add static build to our CI to be safe for such regressions. Would you agree?

muggenhor commented 6 years ago

Yes, I agree: testing that right now. This build should fail if my CI setup is correct: https://travis-ci.org/muggenhor/cucumber-cpp/jobs/387151301

muggenhor commented 6 years ago

And for some reason this doesn't fail on CI. I guess it's the older CMake version (3.2.2). I'll leave the static library build in anyway, just to ensure we're testing the configuration option in both directions.