Skip to content

Update Travis Configuration #848

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 12 commits into from
Jan 4, 2019
Merged

Update Travis Configuration #848

merged 12 commits into from
Jan 4, 2019

Conversation

deanberris
Copy link
Member

This change makes the build matrix explicit, and allows us to upgrade the CI infrastructure to use:

  • Newer compilers: GCC [4.9, 5.0], Clang [3.8, 3.9, 4.0, 5.0]
  • Updated distribution: from Precise to Trusty

In the future, we can also test on OS X and start retiring support for older compilers when we start moving to using C++14 features in the library.

@deanberris deanberris requested a review from glynos June 14, 2018 10:01
@deanberris
Copy link
Member Author

Hi @glynos -- we're currently finding build breakages in the URI library in master, with the use of C++14 features. I'm not sure whether we just need to update the master submodule, but I'd like to see this change merged (and then get us back to 'green' on the CI dashboard).

Thanks in advance!

@glynos
Copy link
Member

glynos commented Jun 14, 2018

@deanberris are you asking to disable the C++ features from uri? I can take a look later this weekend.

@deanberris
Copy link
Member Author

I think, maybe either that we need to stick to C++11 for master (until we decide to consciously move to C++14), to address issues like these:

In file included from /home/travis/build/cpp-netlib/cpp-netlib/deps/uri/test/uri_test.cpp:9:
In file included from /home/travis/build/cpp-netlib/cpp-netlib/deps/uri/include/network/uri.hpp:35:
In file included from /home/travis/build/cpp-netlib/cpp-netlib/deps/uri/include/network/uri/uri.hpp:22:
/home/travis/build/cpp-netlib/cpp-netlib/deps/uri/include/network/string_view.hpp:164:5: warning: use of this statement in a constexpr function is a C++14 extension [-Wc++14-extensions]
    if (size() != s.size())
    ^
/home/travis/build/cpp-netlib/cpp-netlib/deps/uri/include/network/string_view.hpp:166:5: warning: multiple return statements in constexpr function is a C++14 extension [-Wc++14-extensions]
    return traits::compare(data(), s.data(), size());
    ^
/home/travis/build/cpp-netlib/cpp-netlib/deps/uri/include/network/string_view.hpp:165:9: note: previous return statement is here
        return size() < s.size() ? -1 : 1;
        ^
2 warnings generated.

Note that the Travis builds are now half-green (clang builds work just fine but the GCC builds complain about the constexpr warning).

@glynos
Copy link
Member

glynos commented Jun 14, 2018

@deanberris try now with the tip of master

@deanberris
Copy link
Member Author

Thanks @glynos -- I think the problem is the code, in that it's actually using an if statement. Let me send you a PR to try and address that specific issue.

@deanberris deanberris force-pushed the travis-upgrade-compilers branch from 4a6fbe4 to e056ad2 Compare June 19, 2018 03:37
@deanberris
Copy link
Member Author

Rebased on top of the new URI tip of master, now running the checks through the travis config.

@deanberris
Copy link
Member Author

Hi @glynos -- I'm seeing this issue with the latest in the URI library:

[  1%] Building CXX object deps/uri/src/CMakeFiles/network-uri.dir/uri.cpp.o
cd /home/travis/build/deanberris/cpp-netlib/build/deps/uri/src && ccache /usr/bin/clang++-3.8  -DBOOST_NETWORK_ENABLE_HTTPS -DBOOST_TEST_DYN_LINK -Dnetwork_uri_EXPORTS -I/home/travis/build/deanberris/cpp-netlib/deps/uri/src -I/home/travis/build/deanberris/cpp-netlib/deps/uri/include  -std=c++11 -Wall -ftemplate-depth=256 -std=c++11 -DBOOST_ASIO_HAS_STD_CHRONO -DBOOST_ASIO_HAS_STD_ARRAY -DBOOST_ASIO_HAS_STD_SHARED_PTR -DBOOST_ASIO_HAS_STD_ATOMIC -DBOOST_ASIO_HAS_VARIADIC_TEMPLATES -DBOOST_ASIO_HAS_MOVE -DBOOST_THREAD_VERSION=3 -stdlib=libstdc++ -std=c++14 -Wall -Werror -O3 -DNDEBUG -fPIC   -o CMakeFiles/network-uri.dir/uri.cpp.o -c /home/travis/build/deanberris/cpp-netlib/deps/uri/src/uri.cpp
In file included from /home/travis/build/deanberris/cpp-netlib/deps/uri/src/uri.cpp:8:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/locale:39:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/locale_classes.h:40:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/string:52:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/basic_string.h:2815:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/ext/string_conversions.h:43:
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/cstdio:120:11: error: no member named 'gets' in the global namespace
  using ::gets;
        ~~^

I've updated the latest commit in cpp-netlib's master branch to be the tip of the uri library's master, and this error looks really suspicious to me. We're attempting to build with clang-3.8 with libstdc++ as the standard library, which I know is a supported use-case in the past.

Thoughts?

@glynos
Copy link
Member

glynos commented Jun 19, 2018

It's obviously a configuration error. Are you sure that the header path is the appropriate one?

/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/cstdio:120:11: error: no member named 'gets' in the global namespace

IIUC, gets doesn't belong in any namespace, never mind the global one...

FWIW, I am using clang 3.8 on MacOS it builds with no errors.

@deanberris
Copy link
Member Author

Yeah, I should have said this is in the Travis CI -- you can see the results here:

https://travis-ci.org/cpp-netlib/cpp-netlib/jobs/393936085

Note that Travis does this from scratch all the time, and we're using the clang-3.8 package from the LLVM repository.

@glynos
Copy link
Member

glynos commented Jun 21, 2018

Why do you want to support GCC 4.8?

@glynos
Copy link
Member

glynos commented Jun 21, 2018

I can test it locally using GCC 4.8 and 5, and with no issues.

@glynos
Copy link
Member

glynos commented Jun 21, 2018

And with clang 3.9

@deanberris
Copy link
Member Author

They're all fine, except for clang 3.8 -- which is what's currently failing.

GCC 4.8 is still the default compiler for some of the LTS releases.

@glynos
Copy link
Member

glynos commented Jun 24, 2018

I found the error. Try again using the tip of the uri/master.

@deanberris deanberris force-pushed the travis-upgrade-compilers branch from 3d2dd20 to 61b166f Compare January 4, 2019 05:11
@glynos
Copy link
Member

glynos commented Jan 4, 2019

LGTM

@glynos glynos merged commit 7337516 into cpp-netlib:master Jan 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@glynos glynos Awaiting requested review from glynos

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@deanberris @glynos