Używanie alternatywnego kompilatora dla projektów Travis-CI R:

Question

Obsługa Travis-CI official R project build w systemie Ubuntu (w tym pytaniu) gcc wersja 4.6.

Aplikacja CRAN używa gcc 4.9, a niektóre pakiety, które budowane są prawidłowo na CRAN, nie będą budowane na Travis z gcc 4.6.

Jak zmienić domyślny kompilator gcc dla kompilacji projektu/pakietu R, aby lepiej odzwierciedlać kompilacje CRAN?

Answer 1

Naprawdę chciałem móc użyć Travisa do przetestowania mojego pakietu ndjson, ale biblioteka C++, której używam, nie będzie się kompilować pod gcc 4.6.

Pakiet ndjsonjest na CRAN i CRAN builds are fine (z wyjątkiem r-oldrel w systemie Windows, który nie przeszkadza mi trochę), więc potrzebowałem sposób zmienić kompilator, że R używa na Travisa.

Używam gcc 5 w poniższym przykładzie, ale możesz użyć dowolnej wersji dostępnej w toolchain test builds. Najlepiej byłoby naśladować wersję CRAN gcc i może to być coś, co ludzie z Travis mogliby uznać za domyślną dla wersji R.

W .travis.yml zaczyna się tak samo:

language: r 
warnings_are_errors: true 
sudo: required 

env: 
global: 
    - CRAN: http://cran.rstudio.com 

Dodałem konfigurację budowania macierzy, aby dodać nowe źródło pakietów, a także określić pakiet (y), że potrzebne do zainstalowania. Zostawiłem to w konfiguracji macierzowej, ponieważ zamierzam spróbować (ostatecznie) dodać clang.

matrix: 
    include: 
    - os: linux 
     compiler: gcc 
     addons: 
     apt: 
      sources: ['ubuntu-toolchain-r-test'] 
      packages: ['g++-5'] 
     env: 
     - COMPILER=g++-5 
     - CC=gcc=5 
     - CXX=g++-5 

Następnie zrobiłem pewien, że auto domyślny kompilator jest ustawiony na ten nowszy gcc a także podwójnie pewny, że R użyłby go tworząc lokalny Makevars:

before_install: 
    - sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-5 100 
    - mkdir -p ~/.R 
    - echo "VkVSPS01CkNDPWdjYyQoVkVSKSAtc3RkPWMxMSAKQ1hYPWcrKyQoVkVSKQpTSExJQl9DWFhMRD1nKyskKFZFUikKRkM9Z2ZvcnRyYW4KRjc3PWdmb3J0cmFuCg==" | base64 -d > ~/.R/Makevars 
    - cat ~/.R/Makevars 

ciąg base64 równa się :

VER=-5 
CC=gcc$(VER) -std=c11 
CXX=g++$(VER) 
SHLIB_CXXLD=g++$(VER) 
FC=gfortran 
F77=gfortran 

i jest po prostu (IMO) czystszy w ten sposób.

Teoretycznie wszystko bym musiał zrobić, to stworzyć Makevars (czyli nie trzeba zmieniać domyślnego gcc z update-alternatives), ale okazało się, że Travis używane ustawienia Makevarsgcc podczas instalowania zależności ale nie za rzeczywiste sama kompilacja pakietu. Tak więc konieczna jest wersja update-alternatives. Musiałem także dodać -std=c11, aby zapewnić skompilowanie kilku zależności (kompilacja nie powiodła się).

Po wprowadzeniu tych modyfikacji w konfiguracji .travis.yml, poprawiono wbudowanie ndjson.

Answer 2

Aby zastosować alternatywne podejście, używam niestandardowego skryptu powłoki w jednym z moich pakietów sourcetools. Moim celem było zapewnienie, że pakiet będzie budowany przy użyciu (obecnie pradawnego) kompilatora gcc-4.4.W .travis.yml, mam:

language: r 
cache: packages 
sudo: false 
warnings_are_errors: true 

before_install: 
    - source travis/before-install.sh 

addons: 
    apt: 
    packages: 
     - gcc-4.4 
     - g++-4.4 
     - clang 

r: 
    - oldrel 
    - release 
    - devel 

env: 
    - COMPILER=gcc-4.4 
    - COMPILER=gcc 
    - COMPILER=clang 

I travis/before-install.sh, mam:

#!/usr/bin/env sh 

mkdir -p ~/.R 

if [ "${COMPILER}" = "gcc-4.4" ]; then 
    echo "CC=gcc-4.4 -std=gnu99" >> ~/.R/Makevars 
    echo "CXX=g++-4.4"    >> ~/.R/Makevars 
    echo "CXX1X=g++-4.4 -std=c++0x" >> ~/.R/Makevars 
fi 

if [ "${COMPILER}" = "gcc" ]; then 
    echo "CC=gcc -std=gnu99" >> ~/.R/Makevars 
    echo "CXX=g++"    >> ~/.R/Makevars 
    echo "CXX1X=g++ -std=c++0x" >> ~/.R/Makevars 
fi 

if [ "${COMPILER}" = "clang" ]; then 
    echo "CC=clang -std=gnu99"  >> ~/.R/Makevars 
    echo "CXX=clang++"    >> ~/.R/Makevars 
    echo "CXX1X=clang++ -std=c++0x" >> ~/.R/Makevars 
fi 

Wynik końcowy jest zasadniczo taki sam, ale IMHO to nieco czystsze oddzielić 'Setup' logiki do własnych skrypt całkowicie wyłączony ze zmiennych środowiskowych. Ułatwia to również konstruowanie buildów macierzy R, ponieważ Travis automatycznie łączy permutacje r i env tutaj (nie ma potrzeby robienia tego "ręcznie").

Wyobrażam sobie, że skrypt, którego używam, może być wyczyszczony/uczyniony bardziej ogólnym, ale nie mam takiej potrzeby.