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

Modification of the Travis tasks #699

Closed
taketwo opened this issue May 26, 2014 · 5 comments
Closed

Modification of the Travis tasks #699

taketwo opened this issue May 26, 2014 · 5 comments

Comments

@taketwo
Copy link
Member

taketwo commented May 26, 2014

A pull request that adds support for vtk6 was merged just a few moments ago (#363). This raises a question if we should devise a separate Travis task to compile/link/test PCL with this version of the library.

I think that we should do this, however

  • only with clang;
  • only compile a subset of targets that actually depend on visualization.

This will minimize the risk of failing due to 50-minute timeout and impose less burden on Travis.

While we are at it, I would also propose to discuss a modification of the build task for gcc. More often than not this task fails due to timeout. This is a) confusing for those contributors who are new to PCL; b) makes Travis status non-informative for maintainers. I think we should articulate why do we want to have both clang and gcc tasks at the same time (i.e. what exactly do we test with the latter). Depending on the goal we should either get rid of if completely, or reduce the amount of targets.

@jspricke
Copy link
Member

+1 for vtk6 build.
+1 for clang only Travis.

@rbrusu
Copy link
Member

rbrusu commented May 26, 2014

+1 for clang only.

The only reason to have GCC is because there might be code that compiles with clang but doesn't with gcc (so far I don't remember seeing any).

@taketwo
Copy link
Member Author

taketwo commented May 26, 2014

there might be code that compiles with clang but doesn't with gcc

Chances are such code will be in the core of PCL, deep inside macros, meta-programs, and alike. What if we keep gcc, but compile only pcl_common, just in case?

@VictorLamoine
Copy link
Contributor

For the future: Migrating from legacy to container-based infrastructure
This will allow using ccache and thus much faster build times.

@SergioRAgostinho
Copy link
Member

For the latest updates on the topic #1786 #1892.

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

No branches or pull requests

5 participants