Więcej o firmie ELESOFTROM

Firma ELESOFTROM specjalizuje się w wykonywaniu i naprawianiu oprogramowania dla sterowników mikroprocesorowych.

Posiadamy ponad 10-letnie doświadczenie w tej dziedzinie.

W realizowanych projektach stawiamy na niezawodność i wydajność programów.

Naprawa oprogramowania

Oprogramowanie na zamówienie


Strona główna

Pełna oferta

Doświadczenie

O firmie

Kontakt

DioneOS - RTOS dla urządzeń embedded

Firma ELESOFTROM opracowała system RTOS dla procesorów ARM Cortex-M3 oraz msp430.

System jest zoptymalizowany pod względem wydajności, dzięki czemu uzyskano krótki czas przełączania pomiędzy wątkami.
System dostarcza elementy (np. semafory, mutexy, timery, kolejki itp.) niezbędne do tworzenia wielowątkowego firmware'u.

Wersja dla Cortexa została całkowicie przetestowana przy pomocy środowiska do automatycznego testowania.

Przeczytaj więcej:

Strona o systemie DioneOS

Niezawodność

Wydajność

Dokumentacja DioneOSa

Prezentacje n.t. DioneOS

^ Blog index    << Jak zbudować projekt C++ Buildera pod Eclipse (wersja uproszczona)    >> Preprocesor C - podstawy

Budowanie projektu C++ Buildera pod Eclipse (z użyciem GNU make)

2014-11-07    dr inż. Piotr Romaniuk

Spis treści

Jak podczepić projekt z C++ Buildera pod Eclipse.
Dlaczego GNU make i MSYS?
Makefile Borlanda
Rozbieżności pomiędzy narzędziami GNU i Borlanda
Generowanie zależności
Drzewo budowania (porządki w katalogach)
Podsumowanie zmian w makefile
Linki

Dlaczego GNU make i MSYS?

  • środowisko MSYS dość dobrze udaje środowisko Linuxa (shell, podstawowe programy: grep, awk, sed, itp.) - daje to dużą swobodę w realizacji różnych zadań automatycznego przetwarzania plików (np. automatyczne pakowanie plików wynikowych, oznaczanie wersji, itp.),
  • GNU make jest posiada większe możliwości, jest nowszy, bardziej dopracowany niż make Borlanda (w C++ Builderze 6.0),
  • GNU make jest bardzo szeroko wykorzystywany, istenieje wiele opisów w sieci dotyczących rozwiązań różnych problemów za jego pomocą,
  • GNU make jest standardem
  • Przekształcenie do MSYS/GNU-make otwiera drogę do wykonania całego procesu budowania pod GCC (kompilatorem,
    który jest znacznie nowocześniejszy i lepszy niż kompilator C++ Borlanda)

Makefile Borlanda

Cały opis projektu jest przechowywany przez IDE Borlanda (i.e. C++ Buildera) w pliku .bpr w formacie XML. Z tego pliku można wygenerować makefile za pomocą narzędzia bpr2mak.exe Makefile Borlanda jest dość specyficzny i wymaga przekształcenia aby mógł być użyty z GNU make.
Poniżej wymienionych jest kilka różnic (pełny opis jest dostępny tutaj):

  • polecenia (dyrektywy) rozpoczynają się od wykrzyknika (np. !if ) lub kropki (np. .autodepend )
  • dostępne są specjalne (predefiniowane) makra:
    • $d  - 1 gdy następujący parametr jest zdefiniowany,
$*  - nazwa pliku (bez rozszerzenia, ze ścieżką)
$<  - pełna nazwa pliku (z rozszerzeniem, ze ścieżką)
$:  - tylko ścieżka
$.  - nazwa pliku z rozszerzeniem (bez ścieżki)
$&  - nazwa pliku bez rozszerzenia (bez ścieżki)
$@  - pełna nazwa pliku wynikowego (targetu w regule)
$** - wszystkie zależności
$?  - zależności które są nieaktualne
MAKEDIR - katalog w jakim uruchomiono program make
  • stosuje stary format reguł typu implicit (np. .cpp.obj: ... )
  • dostarcza polecenia .autodepend - automatyczne wyznaczanie zależności
  • pozwala podmieniać fragmenty zmiennych $(ZMIENNA:wzorzec=zamieniony_na)
  • daje możliwość wskazania lokalizacji plikow o określonych rozszeżeniach (zmienne .path.c, .path.obj itp.)
  • stosuje pliki tymczasowe, do wykonywania serii poleceń (@&&! - !)

Rozbieżności pomiędzy narzędziami GNU i Borlanda

  • inny format ścieżek (Borland oczekuje DOSowego formatu, np. c:\katalog\plik, podczas gdy narzędzia GNU (tj. MSYS) używa linuxowego, np. /c/katalog/plik)
  • zestawy opcji są podawane u Borlanda w jednym ciągu rozdzielone średnikami (np. definicje symboli, albo ścieżek)

Generowanie zależności

Zależności określają które pliki należy przebudować, dzięki czemu zmniejszają nakład potrzebny do zbudowania pliku wykonywalnego. Przykładowo wykonanie zmiany w jednym module (plik .cpp) pociąga za sobą konieczność skompilowania go do pliku .obj a następnie przebudowania pliku wykonywalnego .exe. Podobnie zmiana w jakimś nagłówku, pociąga za sobą konieczność przebudowania tylko tych modułów które uzywają tego nagłówka.

U Borlanda wyznaczanie zależności działo się automatycznie (dyrektywa .autodepend), w GNU make trzeba to zrobić samodzielnie, chociaż ze znaczną pomocą kompilatora GCC, który może generować te zależności automatycznie (opcje -MM).

Istnieje wiele sposobów w tworzy i używa się zależności, ja wybrałem:
- pliki zawierające zależności w postaci reguł (wygenerowane przez GCC) - pliki o rozszerzeniach .d
- aby zachować zgodność rozszerzenia pliku skompilownego modułów (obj) w tych regułach podmieniane są rozszerzenia z .o na .obj
- włączanie plików do makefile'a poprzez -include (są traktowane jako dodatkowe reguły)
- generowanie zależności na żądanie (target deps)

Przykładowe zależności (plik main1.d): 

main1.obj: main1.cpp main1.h ../firmware/fclock.h ../firmware/protocol.h

Aby zbudować zależności należy wykonać (z linii poleceń konsoli windows): 

build_by_gnumake.bat deps

albo z konsoli MSYS: 

make -f hello1_gnu.mak deps

Budowanie zależności robi się dość rzadko i jest wymagane gdy zmienia się włączane pliki nagłówkowe lub dodaje nowe moduły. Można ew. pokusić się o automatyczne budowanie zależności.

Drzewo budowania

Domyślnie Borland C++ Builder tworzy wszystko w jednym katalogu. Niestety prowadzi to do bałaganu - zmieszane są pliki źródłowe oraz wynikowe. Można nad tym zapanować podając oddzielne katalogi w oknie właściwości projektu, zakładka Directories/Conditionals (poniżej zostały te katalogi ustawione odpowiednio na build i _stage):

Oczywiście również w GNU makefile można zapanować nad lokalizacją plików, podając katalog wynikowy jako prefix: 

$(BUILD_PREFIX)/%.obj : %.cpp 
	$(BCC32) $(CFLAG1) $(WARNINGS) "-I$(INCLUDEPATH)" "-D$(USERDEFINES);$(SYSDEFINES)" $< -o$@

Podsumowanie zmian w makefile

W celu uzyskania możliwości użycia GNU make należy wprowadzić następujące zmiany w makefile'u Borlanda:

  • zamienić polecenia warunkowe - są to głównie definicje dla symboli, które nie są zdefiniowane
  • dostarczyć zależności
  • używać ścieżek w formacie linuxowym i DOSowym - odpowiednio do tego czy wskazują na wykonywany program czy są użyte w argumentach narzędzi Borlanda
  • otoczyć ścieżki DOSowe cudzysłowami - aby interpreter MSYS nie reagował na backslashe oraz średniki w treści ścieżek
  • zastąpić użycie plików tymczasowych listą poleceń

Przykładowy projekt kompilowany w Eclipse za pomocą GNU make narzędziami Borlanda.

Linki

  1. Opis narzedzi Borlanda (kompilator, linker, itp.) - znaczenie parametrów podawanych z linii poleceń
  2. Opis składni makefile Borlanda,
  3. Strona projektu MinGW/MSYS