Wspólne pliki object dla każdego targetu w projekcie CMake

0

Mam w projekcie wiele targetów (dynamiczna biblioteka + testy). Przy budowaniu każdy target otrzymuje swój własny katalog na pliki object postaci "projekt/CMakeFiles/target.dir". Z tego powodu kompilacja zajmuje bardzo dużo czasu. Czy da się ustawić współdzielenie tych plików dla każdego targetu? Wspólny katalog czy coś w tym stylu? Im więcej testów, tym kompilacja zajmuje dłużej, co jest bardzo niewygodne.

0
arciobus napisał(a):

Przy budowaniu każdy target otrzymuje swój własny katalog na pliki object postaci "projekt/CMakeFiles/target.dir". Z tego powodu kompilacja zajmuje bardzo dużo czasu.

Skąd ten wniosek? Wróżka ci powiedziała?
Na 100% to nie jest przyczyną.

W C++ główną przyczyną powolnej kompilacji jest burdel w plikach nagłówkowych.
Jednym z narzędzi, które pomaga jest https://github.com/include-what-you-use/include-what-you-use

Podstawowe zasady czystych plików nagłówkowych i innych sztuczek przyspieszających czas budowania:

  • zero kody w nagłówkach - poza szblonami
  • forward deklaracje, gdzie tylko się da by pozbywać się include w pliku nagłówkowym.
  • rezygnacja z domyślnego destruktora wirtualnego (definicja zawsze w cpp nawet jak jest pusta)
  • include what you use
  • posługiwanie się interfejsami by separować logicznie fragmenty kodu.
  • dzielenie projektu na mniejsze cześci.
0

Wniosek prosty - do każdego testu dodaję wszystkie pliki src użyte równie w bibliotece - wybieranie plików do każdego testu byłoby doś uciążliwe oraz mam też testy, które wymagają prawie całego kodu. Podczas kompilacji widać wielkrotnie kompilowane te same pliki. Jeżeli byłaby możliwość współdzielenia plików obiektowych, skróciłoby to kompilację wielokrotnie.

1

Jeśli jedne źródła budują ci się wielokrotnie (ale nie z powodu zmiany konfiguracji) to znaczy, że masz źle zorganizowany projekt.
Źródła produkcyjne zamknij w statycznej bibliotece, którą dołączysz do aplikacji końcowej i do testów.
W ten sposób zarówno testy jak testy będa korzystać z jednego builda.

0

Jak wielokrotnie mielisz te same pliki, to pewnie się da naprawić CMake’a tak, by przestał (ale to jest coś, co mnie przerasta — tego systemu budowania nie znam wcale).

Ale można też użyć ccache’a i nie kombinować.

0

Dolinkowałem dynamiczną bilbiotekę do testów i kompilacja trwa parę razy krócej. Jedyny minus tego rozwiązania to zależność binarek od tej biblioteki. Po usunięciu pliku, testy już nie działają. Szybki workaround - bliblioteka statyczna, która linkowana jest potem do testów i do biblioteki dynamicznej. Ale wygodniej byłoby, współdzielić pliki object - byłoby to bardziej intuicyjne.

0

Mam pytanie a co w przypadku, kiedy kod produkcyjny i kod testowy ma inną konfigurację?
Przykładowo dla testów masz -DJAKASOWARTOSC=3? Albo inny poziom ostrzeżeń?
ccache uzna to za dostateczną różnicę, by ponownie budować od początku te same źródła.
Jak masz bibliotekę o wtedy wiadomo, że ma ona swoje włąsne ustawienia build-a i nie wpadniesz w takie pułapki.
Dla mnie osobna biblioteka jest bardziej intuicyjna i zrozumiała

0

W sumie obecne rozwiązanie jest wystarczające. Wszystko działa, małe zmiany nie powodują pełnej rekompilacji. Akurat w moim przypadku nie mam osobnych konfiguracji dla żadnego z testów.

1 użytkowników online, w tym zalogowanych: 0, gości: 1