it would be good to have some guidance of the settings to be used with travisci and c++14. rstanarm currently cannot serve as an example, because it fails on travis for some other reason. My own attempts showed moderate progress only:
dotR <- file.path(Sys.getenv("HOME"), ".R")
if (!file.exists(dotR)) dir.create(dotR)
MAKEVARS <- file.path(dotR, "Makevars")
if (!file.exists(MAKEVARS)) file.create(MAKEVARS)
"\nCXX14FLAGS=-O3 -mtune=native -march=native -Wno-unused-variable -Wno-unused-function -Wno-macro-redefined",
"CXX14 = g++", # could also you clang++ but your compiler may have a version number postfix
file = MAKEVARS,
sep = "\n",
append = TRUE
or the equivalent so that CXX14 gets defined (although I would have thought it already is if you are using R >= 3.4.0).
g++ -std=c++1y -shared -L/home/travis/R-bin/lib -o rstan.so chains.o init.o lang__ast_def.o lang__grammars__bare_type_grammar_inst.o lang__grammars__expression07_grammar_inst.o lang__grammars__expression_grammar_inst.o lang__grammars__functions_grammar_inst.o lang__grammars__indexes_grammar_inst.o lang__grammars__program_grammar_inst.o lang__grammars__semantic_actions.o lang__grammars__statement_2_grammar_inst.o lang__grammars__statement_grammar_inst.o lang__grammars__term_grammar_inst.o lang__grammars__var_deccls_grammar_inst.o lang__grammars__whitespace_grammar_inst.o misc.o pointer-tools.o sparse_extractors.o stanc.o
/usr/bin/ld: chains.o: relocation R_X86_64_32 against `_ZGVZ7dataptrP7SEXPRECE3fun’ can not be used when making a shared object; recompile with -fPIC
chains.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [rstan.so] Error 1
@Charles_Driver: everything green with fPIC. I had seen that message but was somehow lost in compilation.
@boogri: flto=thin fails
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
Both with and without flto works during off-peak time in travis - nothing changed from yesterday’s on-peak failed build. I wish they would create better error messages when something fails because of technical limitations with the system.
I tried several times this morning to restart. With unchanged code, the success rate is absolutely erratic. Most frequently “the job did not respond withing 10 minutes”, but there are cases where logging end in the middle of nowhere without any error message. Build times run from 13 to 48 minutes. There is some indication that with flto there are more failures, possibly because optimization needs time.
Looks like the free version of Travis cannot reliably handle rstan because of timeout and memory constraints.
It’s difficult to created a stripped-down example that shows it. My minimal https://github.com/dmenne/teststan already needs 18 minutes in the early morning CET. I fear they don’t love these long-running compiles in the free scheme anyway; I can understand that, they have to make some $$$.
gitlab might provide an altnative, because they allow for a docker base image, but I could not get it to work yet, still “searching for runner” (they are all in Hawaii nowadays playing Ironmen).
As an alternative, I have set up a gitlab CI, linking to GitHub. Too bad, it’s a feature that will no longer be available after March 2019.
To celebrate this release, we’re offering this feature promotionally as part of GitLab.com Free through March 2019.
GitLab wants to get the full share of GitHub, so you can continue to use it when you keep your files on a public GitLab repository
This is much faster than TravisCI (9 minutes compared to 20-Inf) , because it uses a prebuild docker image dmenne/stanverse, child of rocker/shiny. Not the full “start from scratch approach”, but that anyway will be done on winbuilder/r-hub.