Cum se poate evita redefinirea VERSIUNII, PACHETULUI, etc

Nu am vazut niciun fel de intrebari referitoare la build-urile GNU autoconf / automake, dar sper ca cel putin unii dintre voi sa o cunoasteti. Aici merge:

Am un proiect (îl voi numi proiectul meu) care include un alt proiect (furnizor). Proiectul vânzătorului este un proiect independent susținut de altcineva. Includerea unui astfel de proiect este destul de simplu , dar în acest în cazul în care există o mică problemă: fiecare proiect generează propriul fișier config.h , fiecare definind macro-uri standard, cum ar fi PACHET, VERSIUNE etc. Aceasta înseamnă că, în timpul construirii, atunci când furnizorul este construit, am o mulțime de erori ca aceasta:

... warning: "VERSION" redefined
... warning: this is the location of the previous definition
... warning: "PACKAGE" redefined
... warning: this is the location of the previous definition

Acestea sunt doar avertismente, cel puțin pentru moment, dar aș vrea să scap de ei. Singurele informații relevante pe care le-am putut genera cu o căutare Google sunt acest pe lista de discuții automake, care nu este o mulțime de ajutor. Mai are cineva idei mai bune?

 0
adăugat editat
Vizualizări: 9
sursa
fr hi bn

3 răspunsuri

Se pare că a existat o soluție foarte simplă în cazul meu. Proiectul vânzătorului adună mai multe fișiere antet într-un fișier antet monolit, care este apoi #include d de către sursele furnizorului. Dar regula de construire care construiește antetul monolitic a inclus în mod accidental config.h generate. Prezența variabilelor config din PACHET, VERSION etc. în antetul monolitic este ceea ce a cauzat avertismentele de redefinire. Se pare că codul config.h al vânzătorului a fost irelevant, deoarece "config.h" a fost întotdeauna rezolvat la $ (top_builddir) /config.h .

Cred că acesta este modul în care ar trebui să funcționeze. În mod implicit, un subproiect ar trebui să includă config.h în locul propriului proiect, cu excepția cazului în care subproiectul include în mod explicit propriul sau manipulează calea INCLUDE, astfel încât propriul său director să vină înainte de $ top_builddir) , sau manipulează în alt mod fișierele antet ca în cazul meu.

0
adăugat
sursa

Este cu siguranță un hack, dar am post-proces fișierul autogen'd config.h :

sed -e 's/.*PACKAGE_.*//' < config.h > config.h.sed && mv config.h.sed config.h

Acest lucru este tolerabil în mediul nostru de construcție, dar aș fi interesat într-un mod mai curat.

0
adăugat
sursa

Câteva note:

  • nu ați menționat cum a fost inclus config.h - cu citate sau paranteze unghiulare. Consultați această altă întrebare pentru mai multe informații despre diferența. Pe scurt, config.h este în mod obișnuit inclus în ghilimele, nu în paranteze unghiulare, iar acest lucru ar trebui să facă preprocesorul preferat config.h din directorul propriu al proiectului ce vrei)
  • Spuneți că un subproiect ar trebui să includă config.h în care se află proiectul. În mod normal, acest lucru nu este deloc ceea ce doriți. Subproiectul este independent, iar PACHETUL și VERSIUNEA trebuie să fie cel al subproiectului respectiv, nu al tău. Dacă includeți libxml în proiectul xmlreader, de exemplu, ați dori ca codul libxml să fie compilat cu PACKAGE libxml și VERSION (oricare ar fi versiunea libxml).
  • Este, de obicei, o mare greșeală să includeți config.h din anteturile publice. config.h este întotdeauna privat pentru proiectul dvs. sau subproiectul și ar trebui să fie inclus numai din fișierele .c. Deci, dacă documentația furnizorului dvs. spune că include "vendor.h" și antetul public include config.h într-un fel, atunci acesta este un nu-nu. În mod similar, dacă proiectul dvs. este o bibliotecă, nu includeți config.h oriunde din anteturile dvs. public instalate.
0
adăugat
sursa