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

Enable ccache for speeding up build in CI #1892

Merged
merged 2 commits into from
Jun 26, 2017

Conversation

SergioRAgostinho
Copy link
Member

This PR enables CCache to speed up our builds. Once a build completes, the speed up is very significant, and it should ease our time-out issues.

Note: I started working on this in #1888, but decided to submit this part separately because it's an important feature to have already enabled.

CMakeLists.txt Outdated
@@ -182,7 +195,7 @@ if(CMAKE_COMPILER_IS_CLANG)
SET(CMAKE_C_FLAGS "-Qunused-arguments")
endif()
if("${CMAKE_CXX_FLAGS}" STREQUAL "")
SET(CMAKE_CXX_FLAGS "-ftemplate-depth=1024 -Qunused-arguments -Wno-invalid-offsetof ${SSE_FLAGS}") # Unfortunately older Clang versions do not have this: -Wno-unnamed-type-template-args
SET(CMAKE_CXX_FLAGS "-Wall -Wextra -ftemplate-depth=1024 -Qunused-arguments -Wno-invalid-offsetof ${SSE_FLAGS}") # Unfortunately older Clang versions do not have this: -Wno-unnamed-type-template-args
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should set these as default (I rather vote for removing most of them).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-Qunused-argument is mandatory, otherwise we have a massive warning dump on the console.

Everything else was to be consistent with the flags defined for gcc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But is it needed here, or could we move it to travis?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can test without all of them and let you know what happens. I'm still unsure on what exactly you want to achieve: is it so set as less flags as possible? What about the SSE ones?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So on my local machine, with only the SSE flags active, the compiler output seems to be pretty clean so far.

The -Qunused-argument is necessary only because of a bug in ccache's interaction with clang (which eventually was fixed, but not on the version included in precise). So we can set it conditionally on the value of the TRAVIS env (which is set to true on travis builds).

Copy link
Member

@taketwo taketwo Jun 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Side note: what about switching to Trusty image? Maybe the bug is fixed there.

Copy link
Member Author

@SergioRAgostinho SergioRAgostinho Jun 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the goal of having our tests running under a more recent platform, fully agree.

CMakeLists.txt Outdated
@@ -79,6 +79,19 @@ SET(CMAKE_BUILD_TYPE "${CMAKE_BUILD_TYPE}" CACHE STRING
"Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel Maintainer."
FORCE)

# Explicit request to use CCACHE
if($ENV{USE_CCACHE})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, I don't think forcing people to use ccache is nice. If someone wants to use it, we have a tutorial on the homepage.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only being triggered if the env is explicitly set. Nevertheless this is the most common option I see around. But it will required activating sudo permissions. I'm not really sure the consequences of that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After having a look at both

https://docs.travis-ci.com/user/migrating-from-legacy/
https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments

it seems like we can actually benefit from the memory increase from using sudo: required and increase the number of workers in all make tasks

@SergioRAgostinho
Copy link
Member Author

I think we hit this problem in when moving to Travis standard infrastructure based on KVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56068 I think we started

I disabled SSE flags basically

@SergioRAgostinho SergioRAgostinho force-pushed the ccache branch 3 times, most recently from 2c993ac to f9172fa Compare June 23, 2017 13:41
@SergioRAgostinho
Copy link
Member Author

This PR is finished in terms of the things I wanted to do. I'll just wait for the final feedback from @jspricke regarding the compiler flags, but we can always address that in a new PR later on.

@jspricke
Copy link
Member

I'm fine wie the changes, but should we disable the build-apps task to make get the CI green?

@SergioRAgostinho
Copy link
Member Author

We should. It just means it needs more work to fraction the job. I'll disable it for now and address job fractioning in a new PR.

Regarding the compiler flags comment you made, I still want to know what were your ideas (in more detail) for those.

@jspricke
Copy link
Member

jspricke commented Jun 24, 2017 via email

@SergioRAgostinho
Copy link
Member Author

SergioRAgostinho commented Jun 25, 2017

Yeah sure. Is it just for me to add the "-Wall -Wextra" to clang or are we revising things more deeply? If so, just open an issue to set up the discussion and I'll create the PR after.

On another note, I adopted this job stage approach because I was trying to set up a cache from the "Build Core" stage. After reading a little bit more on how the cache key is generated here, I realised that the cache was not persisting because we set envs with the task being performed (which modifies the cache key) so that we have an actual clue of what is being executed (since ENVs show up in travis GUI). If we drop this for the time being, and simply print something on the console indicating what the job does, maybe this will allow to reenable building the all the apps in acceptable time.

@taketwo
Copy link
Member

taketwo commented Jun 25, 2017

If we drop this for the time being, and simply print something on the console indicating what the job does, maybe this will allow to reenable building the all the apps in acceptable time.

👍 There is a feature request for job "labels", which the Travis team has added to their roadmap. So for the time being maybe drop env variables and add more build stages (separate extended builds and tests, docs). And adopt the label feature later this year when it is implemented.

Another Travis option we may add to save a tiny bit of time: clone depth.

@SergioRAgostinho
Copy link
Member Author

I made some tests yesterday in another branch and the caching feature from ccache is not really storing that much yet. Better to just merge this one in the meantime.

Another Travis option we may add to save a tiny bit of time: clone depth.

Isn't this gonna cut the build very residually?

@taketwo
Copy link
Member

taketwo commented Jun 25, 2017

Isn't this gonna cut the build very residually?

Yes, will only save several seconds and some bandwidth for Travis. But why not.

The caching feature from ccache is not really storing that much yet.

So in the end of the day we are not gaining anything here?

@SergioRAgostinho
Copy link
Member Author

So in the end of the day we are not gaining anything here?

I can't tell at the moment but something is weird. There's no single ccache hit... You can check what I'm doing here https://travis-ci.org/SergioRAgostinho/pcl

@SergioRAgostinho
Copy link
Member Author

Basically there's no single ccache hit whenever we use clang on linux and I don't think ccache is working properly on osx, just with instructions specified in Travis.

@taketwo
Copy link
Member

taketwo commented Jun 25, 2017

I'm afraid I'm not much of a help here, never used ccache, even locally.

@SergioRAgostinho
Copy link
Member Author

SergioRAgostinho commented Jun 25, 2017

It's kinda weird. I tried it locally on my environment and thing works exactly as described on Travis' instructions.

On osx, ccache is simply not being picked up properly by cmake and the cache is not written at all. I even tried to explicitly set the compiler path to ccache, but somehow it still resolves to the the clang binary directly.

@SergioRAgostinho
Copy link
Member Author

Ok, guys I'm just waiting for you to merge this one, for me to open another one, enabling a couple of jobs in osx.

@jspricke jspricke merged commit 08e9ebc into PointCloudLibrary:master Jun 26, 2017
@SergioRAgostinho SergioRAgostinho deleted the ccache branch September 21, 2017 01:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants