2013-11-27 22 views
8

Pracuję nad projektem C++, który używa autoconf & automake i staram się poprawnie skonfigurować ścieżki dołączania w *CPPFLAGS. Przeczytałem około 3 godzinnej wartości dokumentów i nie mogę tego jeszcze rozgryźć. Nie szukam hackera, ale poprawny sposób na zrobienie tego. Oto moja zagadka.sposób ustawiania ścieżek dołączania za pomocą autotools

Jak ja to widzę, są 3 zupełnie różne źródła obejmują ścieżki:

  1. zewnętrznych bibliotek, które muszą zostać zainstalowane wraz z moim pakiecie, które są skonfigurowane przez configure --with-XXX=<PATH>.
  2. W moim pakiecie niektóre pliki źródłowe używają #include <file.h>, nawet jeśli file.h jest częścią pakietu, więc aby skompilować je, muszę poprawnie ustawić ścieżkę dołączania. (Uwaga: edytowanie wszystkich tych plików nie jest możliwe.)
  3. Klasyczne (lub nie) standardy określają, że użytkownik musi mieć możliwość określenia własnych (dodatkowych) ścieżek. To znaczy, nie powinienem w ogóle ustawiać CPPFLAGS.

W mojej obecnej konfiguracji:

  • Type 1 ścieżki są ustawione wewnątrz configure.ac przez AC_SUBST(CPPFLAGS, "$CPPFLAGS -I<path>").
  • Ścieżki typu 2 są ustawione wewnątrz Makefile.am przez test_CPPFLAGS = -I<path>.
  • Nie można ustawić typu 3. Dokładniej, jeśli użytkownik ustawi CPPFLAGS przed uruchomieniem make, spowoduje to zastąpienie ustawień typu 1, powodując niepowodzenie kompilacji. Oczywiście, użytkownik może spróbować użyć CXXFLAGS zamiast tego, ale ten ma inne zastosowanie (pamiętaj, proszę o poprawny sposób, aby to zrobić, a nie hack).

Próbowałem to naprawić, ustawiając ścieżki typu 1 za pomocą AM_CPPFLAGS wewnątrz configure.ac. (Dla odniesienia: jeśli ustawisz AM_CPPFLAGS zamiast CPPFLAGS, ale nadal musisz uruchomić pewne sprawdzenia, takie jak AC_CHECK_HEADERS, musisz tymczasowo ustawić CPPFLAGS, a następnie przywrócić je, aby kontrole działały, co zostało wyjaśnione here.) To zwalniaw przypadku ścieżek typu 3, ale niestety kompilacja kończy się niepowodzeniem, ponieważ Makefile -s, która zostanie wyprodukowana przez configure, będzie używać tylko AM_CPPFLAGS, jeśli nie istnieje wyspecjalizowana <target>_CPPFLAGS. Jeśli więc istnieje test_CPPFLAGS ze ścieżką typu 2, kompilacja test zakończy się niepowodzeniem, ponieważ nie ma ścieżki typu 1.

Poprawką byłoby określenie wewnątrz Makefile.am, aby zawsze używać AM_CPPFLAGS. Ale czy to "z książki"? Czy mogę to zrobić w sposób globalny, czy też muszę edytować każdy pojedynczy target_CPPFLAGS? Czy istnieje inne "prawidłowe" rozwiązanie?

+0

Przez "kapryśny", czy należy dołączyć oficjalną dokumentację autokonf, która wyraźnie stwierdza, że ​​CPPFLAGS jest zmienną użytkownika nie powinna być modyfikowana przez opiekuna? (Patrz rozdział 4.8.1 na stronie http://www.gnu.org/software/autoconf/manual/autoconf.html) –

+0

Chociaż mniej niejednoznaczny przykład z oficjalnej dokumentacji automake może być wyraźniejszy, co stwierdza: "Nigdy nie powinieneś redefiniować zmienna użytkownika, na przykład CPPFLAGS w pliku Makefile.am. " w sekcji 27.6 na http://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html#Flag-Variables-Ordering –

Odpowiedz

18

Wiem, że trudno jest uzyskać prostą odpowiedź z podręczników autotools. Jest kilka dobrych samouczków od początku do końca here i here.

Nie ma standardowej zmiennej specyficznej dla pakietu *CPPFLAGS w autoconf. configure można wywołać za pomocą CPPFLAGS=..., a automake doda tę CPPFLAGS do odpowiednich reguł pliku makefile - wyszukaj na przykład CPPFLAGS w pliku Makefile.in.Z tego powodu sugeruję, abyś nie używał tej zmiennej do niczego innego.

Dodaj flagi w Makefile.am do zmiennej AM_CPPFLAGS (domyślne dla wszystkich wywołań preprocesora) lub zastąp poszczególne flagi preprocesora za pomocą target_CPPFLAGS. W przykładzie z 3rd biblioteki partii, to najlepiej użyć nazwy jak: FOO_CPPFLAGS trzymać opcje preprocesora np

FOO_CPPFLAGS="-I${FOO_DIR}/include -DFOO_BAR=1" 
... 
AC_SUBST(FOO_CPPFLAGS) 

aw Makefile.am:

AM_CPPFLAGS = -I$(top_srcdir) $(FOO_CPPFLAGS) 
# or: 
target_CPPFLAGS = -I$(top_srcdir) $(FOO_CPPFLAGS) 

Zmienna top_srcdir jest zdefiniowany przez configure - Używam go do zilustrowania drugiego przypadku. Załóżmy, że masz file.h w innym katalogu other, w katalogu najwyższego poziomu. -I$(top_srcdir) pozwala na włączenie go jako <other/file.h>. Alternatywnie, -I$(top_srcdir)/other pozwoliłoby ci dołączyć go jako <file.h>.

Kolejny użyteczny numer preset variable to srcdir - aktualny katalog. -I$(srcdir) został dodany do AM_CPPFLAGSdomyślnie. Jeśli więc file.h znajduje się w bieżącym katalogu, możesz dołączyć go do <file.h> lub nawet "file.h". Jeśli other był katalogiem "siostrzanym", -I$(srcdir)/.. pozwoliłoby na włączenie <other/file.h>, a -I$(srcdir)/../other pozwoliłoby na <file.h>.


Chciałbym również dodać, że niektóre pakiety zainstalować pkg-config .pc pliku. Pod warunkiem, że instalacja pkg-config jest skonfigurowana do przeszukiwania właściwych katalogów, bardzo przydatne może okazać się makro PKG_CHECK_MODULES.

+2

Innym jest '$ (builddir)' lub '$ (top_builddir) 'który najwyraźniej ma być używany dla plików generowanych podczas kompilacji. – CMCDragonkai

Powiązane problemy