Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix OSX build failing on warning #184

Closed
wants to merge 6 commits into from
Closed

Conversation

konserw
Copy link
Contributor

@konserw konserw commented Feb 14, 2018

Summary

fix OSX build by removing -werror

Details

Motivation and Context

OSX builds started failing becouse of harmless warning treated as error

How Has This Been Tested?

Types of changes

  • Bug fix (non-breaking change which fixes an issue).
  • New feature (non-breaking change which adds functionality).
  • Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist:

  • It is my own work, its copyright is implicitly assigned to the project and no substantial part of it has been copied from other sources (including Stack Overflow). In rare occasions this is acceptable, like in CMake modules where the original copyright information should be kept.
  • I'm using the same code standards as the existing code (indentation, spacing, variable naming, ...).
  • I've added tests for my code.
  • I have verified whether my change requires changes to the documentation
  • My change either requires no documentation change or I've updated the documentation accordingly.
  • My branch has been rebased to master, keeping only relevant commits.

@coveralls
Copy link

coveralls commented Feb 14, 2018

Coverage Status

Coverage remained the same at 63.329% when pulling 879a13a on konserw:osxfix into 70fa12c on cucumber:master.

@matlo607
Copy link
Contributor

What are those harmless warnings ?

@konserw
Copy link
Contributor Author

konserw commented Feb 14, 2018

https://travis-ci.org/cucumber/cucumber-cpp/jobs/341094255 ->

In file included from ../examples/CalcQt/features/step_definitions/BoostCalculatorQtSteps.cpp:4:
../examples/CalcQt/features/step_definitions/CalculatorQtSteps.cpp:40:5: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
    QTest::qWaitForWindowExposed(&ctx->calculator);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

I just tried assigning to a variable which resulted in:
https://travis-ci.org/konserw/cucumber-cpp/jobs/341560068

../examples/CalcQt/features/step_definitions/CalculatorQtSteps.cpp:39:10: error: variable ‘_’ set but not used [-Werror=unused-but-set-variable]
     bool _; //just to suppress warning
          ^
cc1plus: all warnings being treated as errors

Honestly I don't think we should add artificial code just to suppress warnings. They are warnings and not errors after all.

@konserw
Copy link
Contributor Author

konserw commented Feb 14, 2018

I'll try with #pragma clang diagnostic ignored "-Wunused-result"

@matlo607
Copy link
Contributor

matlo607 commented Feb 14, 2018

I proposed 1b5ed23 in my pull requests (#180, #181, #182, #183).
The result of QTest::qWaitForWindowShown / QTest::qWaitForWindowExposed should be actually used.

@matlo607
Copy link
Contributor

By the way, do you know who is in charge of reviewing pull requests on this project ?
A lot of pull requests are green and have not been accepted nor rejected.

@konserw
Copy link
Contributor Author

konserw commented Feb 14, 2018

but your use of it doesn't make any sense - that waiting function is there for user to actually see what is happening (how cucumber is "clicking") if user wants to; and by default does nothing (waits for 0 ms)

As for reviewers: @paoloambrosio @muggenhor and I supose me...

@matlo607
Copy link
Contributor

I trust you if you say so. Actually I am not a cucumber user, I just had to build it and provide an artifact for a team and fixed the build with boost-1.66.0
I will remove commit 1b5ed23 from my pull request once you will have fixed this issue.
Thanks for your feedback.

@konserw konserw changed the title fix OSX build by removing -werror fix OSX build failing on warning Feb 15, 2018
@konserw
Copy link
Contributor Author

konserw commented Feb 15, 2018

Ok so the question now is if we need to keep -werror and apply this PR or could we just disable -werror ?
@muggenhor @paoloambrosio what do you think ?

@konserw
Copy link
Contributor Author

konserw commented Mar 20, 2018

I went with disabling -werror on my devel branch. If merging is unblocked I would push it also here.

@matlo607
Copy link
Contributor

Any news about the reviewers ?
This pull request has been opened for more than 1 month ago.

@konserw
Copy link
Contributor Author

konserw commented Mar 21, 2018

@matlo607 could you please create pull request with just removing -werror ? I'll then review and merge it . Afterwords I'll review rest of your PRs (I've already tested them ;) )

konserw added a commit to konserw/cucumber-cpp that referenced this pull request Mar 30, 2018
This is group-merge which consist actualy of following fixes:
* Remove -werror compiler flag to fix failing build with clang ([cucumber#184](cucumber#184) Kamil Strzempowicz)
* Add missing virtual destructor in base class SocketServer used by TCPSocketServer and UnixSocketServer ([cucumber#183](cucumber#183) Matthieu Longo)
* Fix breaking changes in API of boost-1.66.0 ([cucumber#180](cucumber#180)  Matthieu Longo)
* Fix conflicting "using std" declaration with "using boost::thread" ([cucumber#181](cucumber#181)  Matthieu Longo)
* Fixing Visual Studio 2013 error: no appropriate default constructor available ([cucumber#188](cucumber#188) Antoine Allard)
@konserw
Copy link
Contributor Author

konserw commented Mar 30, 2018

Merged as part of #189

@konserw konserw closed this Mar 30, 2018
@muggenhor muggenhor added this to the v0.5 milestone May 23, 2018
@muggenhor muggenhor mentioned this pull request May 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants