SFML-owe zabawy #2 - Budowanie z TravisCI


2018-07-12, 00:00

Pierwsza iteracja SFML-owych zabaw dobiega końca, czas rozliczyć się z ostatniego tygodnia. Jedziemy! :)


Uwaga. Wszystko, o czym piszę poniżej znajduje się na branchu iteration-1 w repozytorium projektu, o tutaj: https://github.com/CppPolska/MarioEdit/tree/iteration-1. Jeżeli masz uwagi odnośnie kodu, bądź chcesz dołączyć do projektu - daj znać w komentarzu :)

Jakie były plany na ten tydzień?

Podczas pierwszej iteracji chciałem skupić się przede wszystkim na budowaniu projektu. Chciałem wdrożyć coś, co pomoże mi (oraz wszystkim zainteresowanym) w łatwy sposób zbudować cały projekt. Włącznie z bibliotekami których używam (GoogleTest, SFML). Dodatkowym celem było podpięcie całości pod system Continuous Integration, aby czuwał, kiedy człowiek zawiedzie. Na końcu listy znajdowała się poprawka do skalowania okna.

Cytując samego siebie:

  1. Podpięcie źródeł GoogleTest i SFML, aby całość kompilowała się pod systemami Windows/Linux/MacOs w jednakowy sposób
  2. Poprawa skryptu budowania, instrukcja kompilacji i budowania projektu
  3. Propozycja od Wojtka Razika - wdrożenie Continuous Integration - TravisCi?
  4. Poprawa skalowania ViewPort-u przy zmianie rozmiaru okna

Co z tego udało się zrobić?

Skrypt budowania projektu

Najważniejszym celem tego krótkiego sprintu było postawić skrypt budowania projektu. Jedną komendą budujemy cały projekt, puszczamy testy, odpalamy aplikację. Przydała mi się do tego moja znajomość shella. Od teraz, jeżeli chcemy przebudować projekt, w terminalu puszczamy ./console build. Testy uruchamiamy poleceniem ./console test, a program uruchamiamy komendą ./console run. Zastosowane przeze mnie rozwiązanie ma kilka drobnych zalet:

  1. Bardzo duża prostota obsługi. Ktoś, kto nie do końca wie jak działa CMake również może zbudować sobie projekt.
  2. Separuję użytkownika końcowego od technologii, których używam. Jak zmienię bebechy pod spodem, nic nie zmieni się dla osoby budującej projekt.
  3. Nawet Windows obsługuje bash’a, więc jest szansa, że będzie¹ to działało wszędzie tak samo.

Tak to wygląda u mnie:

Szybkie budowanie

Po szczegóły zapraszam tutaj. Co Wy o tym sądzicie? Można było zrobić to inaczej/lepiej?

Podpięcie kodu do TravisCI

Bardzo dużym zaskoczeniem dla mnie było podpięcie do GitHub’a systemu TravisCi. Dosłownie dwa kliknięcia i… to działa! Mega². Co prawda, pierwszy build nie zakończył się sukcesem, ale - tutaj ja zawiniłem. W systemie dostarczanym przez Travis-a brakowało kilku bibliotek, które trzeba aby sobie doinstalował przed rozpoczęciem budowania projektu. Mimo to - na prawdę jest super.

Do budowania oczywiście potrzebny jest plik .travis.yml - jego zawartość jest na tyle mała, że w zasadzie to mogę go tutaj wkleić:

dist: trusty
sudo: false
language: cpp
compiler: gcc

before_script:
  - sudo apt-get install -y libsndfile1-dev libxrandr-dev libudev-dev libopenal-dev build-essential

script:
  - ./console build

Od tej chwili mogę chwalić się ładnym, zielonym obrazkiem:

Build passing

Integracja Travis-a z GitHub-em

Oprócz tego, że dwa kliki i integracja gotowa, bardzo zaskoczyła mnie jeszcze jedna rzecz: mianowicie, przy mergowaniu pull-requesta z kodem, pojawiło mi się przed oczami:

Integracja Travis + GitHub

No po prostu miazga. Tyle wygrać. Może moja ekscytacja jest nadmierna, ale - powiedzcie mi - jak tu się nie cieszyć? :)

Pro tip: pamiętajmy, że nie każdy build passing oznacza, że wszystko się udało. W moim przypadku skrypt budowania wywracał się, ale mimo to Travis pokazywał zielone. Dlaczego tak się stało? Bo proces kompilacji kończył się niepowodzeniem, ale mój skrypt budowania w dalszym ciągu zwracał status 0 (success)..


Czego nie udało się zrobić?

I skończyło się rumakowanie. Aby nie dołować się zbyt długo, zostawię tutaj jedynie krótkie komentarze :)

Kompilacja pod Windows-em

Póki co: nie mam Windows-a. Może ktoś z Was jest chętny tutaj pomóc? :D

Instrukcji jak nie było, tak nie ma

To będzie pierwsza rzecz, za którą zabiorę się w najbliższej iteracji.

Prawie udało mi się zeskalować zawartość okna ;)

Nie do końca o ten efekt mi chodziło:

Szybkie budowanie

Niby głupota, ale - kiedy zrobiłem to, co zrobiłem, uświadomiłem sobie, jak to na prawdę powinno działac. Zawsze jeden plus. I o to chodzi! :)

Jedziemy dalej!

Biję się w pierś, mało czasu miałem w tym tygodniu na cokolwiek. Cieszę się z tego, co jest - bo gdy patrzę na swój ostatni tydzień - niewiele by brakowało, i by nawet tego nie było.

To tyle z retrospektywy, jedziemy z nową iteracją:

  1. Instrukcja budowania
  2. Skalowanie okna - the proper way
  3. Drag-n-Drop na puzelku
  4. Wprowadzenie easing do wydarzeń MouseEnter, MouseLeave i na Drag-n-Drop’ie. W ostatnim numerze magazynu Programista jest coś o tym.
  5. Mruganie puzelka.

Motywacja

Bardzo dużym impulsem motywującym mnie do działania jest to, że nie tylko ja czerpię z SFML-owych zabaw:

Motywacja

Z jednej strony, szkoda że na studiach kod budził postrach Artur, z drugiej jednak - to znaczy, że u mnie nie wygląda to źle! :) +1 dla Ciebie :D

Czekam na Wasze komentarze, a jeżeli macie wolną chwilę i chcecie dołączyć do projektu - to czekam na zgłoszenia, pull-requesty itp.


¹ będzie, bo jeszcze nie wiem czy działa
² tak, pierwszy raz korzystam z TravisCi :)



Marcin Kukliński

Zawodowo backend developer, hobbystycznie pasjonat języka C++. Po godzinach poszerza swoją wiedzę na takie tematy jak teorii kompilacji oraz budowa formatów plików. Jego marzeniem jest stworzyć swój własny język programowania.

Pssst! Używamy Cookies. Poprzez używanie naszego serwisu zgadzasz się na odczytywanie i zapisywanie Cookies w swojej przeglądarce.