Solange header.h nicht in einem Standard Pfad des compilers liegt, sollte die Variante 2 mit unterschiedlichen include und linker Pfaden im Makefile reichen. Du müsstest die parallelen header also in je einem Unterordner ablegen.
Oder
#ifdef LIBA
#include <libname/header.h>
#else
#include <header.h>
#end
plus im pc bei den cflags -DLIBA anhängen
Danke dir für die Antwort. Es geht mir aber eher um den "Library-Teil" der ganzen Geschichte.
Mich hätte einfach generell interessiert ob ich als "Library-Ersteller" dem Nutzer zwei "Optionen" zum Includen meiner Library "ermöglichen" kann. Also entweder mit dem "Prefix-Verzeichnis" oder eben "ohne".
Es geht mir konkret um eine eher "exotische" Library (libmcli zur Ansteuerung des Reel Netceiver) die aktuell als "Abfallprodukt" beim Bauen des VDR-Plugins "abfällt". Das VDR-Plugin selber baut dann statisch gegen die Library und braucht das ".so" gar nicht. Das ".so" wird aber (optional) von minisatip unterstützt um einen bestehenden Netceiver mit dem (wesentlich "gängigeren") Sat>IP Protokoll ansteuern zu können. Für "tvheadend" ist das z.B. die einzige Lösung um die Tuner eines Netceivers nutzen zu können.
Ich möchte das etwas "entflechten". Eigentlich hätte ich lieber die Option die Library ganz ohne VDR kompilieren zu können und das VDR-Plugin kann dann bei der Gelegenheit auch dynamisch gegen die Library bauen.
Minisatip nutzt aktuell Includes ohne "Prefix-Verzeichnis": https://github.com/catalinii/m…ver_mcli_defs.h#L185-L191
Ich würde aber, um potentielle Namensgleichheiten auszuschließen, für eine "saubere" Library lieber Includes der Form
haben. Deshalb mein erster Gedanke: Wenn ich (vorerst) möglichst wenig Anpassung an minisatip haben will, dann muss ich beide Optionen irgendwie anbieten.
Jetzt ist mir aber eingefallen, dass es wohl deutlich einfacher und schöner geht. Es gibt nämlich noch eine weitere Stelle wo minisatip aktuell feste Pfade nutzt: https://github.com/catalinii/m…ter/configure#L4485-L4486
Also warum nicht einfach eine Struktur wie diese:
/usr
'- include
'- libnetceiver
+- netcv
| '- api_server.h
'- mcast
+- common
'- client
'- api_server.hDas Unterverzeichnis "mcast" würde ich dann z.B. nur anlegen wenn mit "make LEGACY=1" gebaut wurde und das "api_server.h" dort macht letztlich nur "#include <netcv/api_server.h> und wirft zusätzlich eine Warnung aus.
Edit: Damit das so geht brauche ich dann vermutlich noch einen Symlink von /usr/include/libnetceiver/mcast/client/netcv nach /usr/include/libnetceiver/netcv (oder einen relativen Include im Legacy-File). Ziel des "make LEGACY" soll ja sein erstmal keine Änderungen am minisatip zu brauchen. Wenn die später doch noch folgen könnte in einer Folgeversion dann "make LEGACY" auch ganz raus.
Sorry für den "Wall of Text" aber ist auch für mich das erste mal wo ich mich mit sowas befasse und ich bin für jedes Feedback dankbar.
Wenn das Plugin dynamisch gegen die lib gebaut würde, dann wäre das einfach eine installierte library. Mit einem Set an includes und .so Dateien.
Das Plugin und minisatip linken dynamisch dagegen und fertig. Ich versteh die Notwendigkeit von Duplikaten nicht.
Das einzige was man checken müsste, ist ob diese lib auch mit -fPic oder -fPIC gebaut wird und ob es eine korrekte Versionierung gibt (Dateinamen und innerhalb der lib als define).
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!