Czym jest Meson?
Meson to open source’owy build system, który z założenia ma być szybki i jak najbardziej przyjazny dla użytkownika. Autorzy twierdzą, że projektując mesona mieli z tyłu głowy, że każda sekunda spędzona przez developera na debugowaniu build systemu jest sekundą zmarnowaną.
By osiągnąć wspomnianą łatwość w użyciu, autorzy mesona narzucili na użytkowników dużo ograniczeń związanych z tym, jak można tworzyć pliki mesona - meson.build. Mianowicie, nie można definiować własnych funkcji oraz makr, a jedynie wykorzystywać zachowanie zdefiniowanych funkcji. Taka decyzja jest poparta jeszcze jednym argumentem. Autorzy dzięki temu mogą wymuszać na użytkownikach podążanie za najlepszymi praktykami, które są obecnie znane w dziedzinie build systemów. Jak to działa w praktyce? Z początku brak funkcji wydawał nam się dużą przeszkodą, ale po tym jak projekt osiągnął pewien stopień dojrzałości, nie wyobrażamy sobie miejsca, gdzie moglibyśmy użyć zdefiniowanych przez nas funckcji.
Czy meson stanie się nowym standardem wśród programistów C/C++? Na to pytanie nie znamy niestety odpowiedzi. Natomiast, poniższy obrazek wydaje się być w dalszym ciągu aktualny.
Dlaczego meson w embedded?
Przede wszystkim szukaliśmy build systemu, który będzie można użyć w projekcie C/C++ embedded oraz którego składnia będzie łatwiejsza w zrozumieniu niż składnia CMake’a. Dodatkowymi kryteriami było zarządzanie zależnościami w projekcie oraz szybkość budowania.
Przykładowa konfiguracja
Dla zobrazowania składni załączamy przykładowy plik meson.build z minimalną konfiguracją:
Bardzo przyjemna w odbiorze składnia, prawda? W naszej opinii również dzięki niej nie było potrzeby tworzenia dedykowanego zespołu do utrzymania i rozwijania build systemu,
Meson a inni?
W codziennej pracy istotne jest by build system, z którego się korzysta pozwalał na jak najszybsze otrzymywanie informacji zwrotnej odnośnie stanu budowania projektu. To wymaga szybkiego działania od build systemu. Jak meson wypada na tle pozostałych narzędzi? Jako, że w mesonie (jak i w CMake’u) należy rozróżnić etap konfiguracji projektu oraz etap budowania, w porównaniu należy również rozróżnić te dwa etapy.
Etap konfiguracji
Scons ma 0 sekund, ponieważ w jego przypadku nie można wyszczególnić osobnych etapów.
Etap budowania
Na powyższym wykresie można zauważyć wpływ backendu na czas budowania. Domyślnym backendem Mesona jest Ninja. W CMake’u jest to Make, natomiast równie popularny zdaje się być również Ninja. Porównując powyższy wykres można dojść do wniosku, że samo użycie Ninjy pozwala na skróceniu czasu budowania o około 20%. A to już jest znacząca różnica, prawda?
Meson z kolei wypada najlepiej jeżeli chodzi o porównaniu obydwóch tych etapów. Może to być spowodowane też tym, że te benchmarki zostały przygotowane przez zespół, który pracuje nad rozwojem Mesona. Natomiast z naszego doświadczenia możemy stwierdzić, że jesteśmy zadowoleni z wydajności, jaką proponuje nam Meson.
Meson cross-compilation
Kompilacja skrośna jest nieodłączną cześcią naszej pracy, dlatego ważne jest dla nas by build system umożliwiał jej skonfigurowanie i łatwe zmienianie ustawień opisujących używane narzędzia kompilacji. W przypadku Mesona jesteśmy w stanie taką konfiguracje przeprowadzić przy pomocy pliku o kładni zbliżonej do TOML-a. Przykład poniżej:
Podsumowanie
Meson to open source'owy build system, który ma być szybki i przyjazny dla użytkownika. Autorzy narzucili ograniczenia związane z tworzeniem plików mesona, ale dzięki temu mogą wymuszać na użytkownikach podążanie za najlepszymi praktykami. Meson wypada najlepiej jeżeli chodzi o czas konfiguracji i budowania projektu. Jest również łatwy do skonfigurowania dla cross-kompilacji.
Referencje
- The Meson Build system - https://mesonbuild.com/
- Design rarionale - https://mesonbuild.com/Design-rationale.html#can-we-do-better
- Comaprisons - https://mesonbuild.com/Comparisons.html
- Add limited user-defined functions? - https://github.com/mesonbuild/meson/issues/3234#issuecomment-1629790749
#EmbeddedSoftware #EmbeddedBuildSystem