[C++] User keuze geven wat gecompileerd wordt in library

[Sissors]

Waarschijnlijk kryptische titel, maar kon niks beters bedenken.

De situatie is C++ op embedded systemen (microcontrollers). Ik heb een eigen library, waarbij ik de gebruiker de mogelijkheid wil geven om een gedeelte niet mee te laten compileren om de memory footprint te verkleinen, is dat mogelijk? En dan dat als de gebruiker niks extras aangeeft gewoon de standaard volledige library wordt gecompileerd.

Met #defines en dan #ifdef kan het, maar van wat ik heb gevonden is de enige 'goede' methode als je dan een .h file met die defines include. En dan moet je dus verplicht altijd als gebruiker een extra .h file maken met de juiste naam (het is niet handig als deze bij de library zelf zit ivm het aanwezige repository systeem: Als je dan de library importeert en een andere configuratie optie kiest moet die library weer gecommit worden, wat niet de bedoeling is).

Zover ik heb kunnen vinden is een #define in main.cpp zetten en die checken in de library geen juiste methode, ook al kan het soms werken.

Wil ik nu iets wat niet kan, of zijn er andere opties? Je zou natuurlijk de libraries kunnen gaan splitsen waarbij je een 'beperkte' library hebt, en dat de 'volledige' die inherit en extra dingen eraan toevoegen. Al wordt het daar niet overzichtelijker van imo.

[farlane]

Macro's ( "#define" ) worden vaak tijdens compileren als compiler/linker optie meegegeven ( -D optie in GCC ) en worden op die manier aan alle compilatieunits meegegeven.

Dit werkt natuurlijk alleen maar als de library niet een precompiled ding is : in dat geval worden ook wel meerdere versies van een library meegeleverd : embedded systemen hebben vaak verschillende versies van de C standard library met bijvoorbeeld geen/beperkte/volledige versies van printf. Dit omdat de volledige versie behoorlijk groot kan zijn en misschien niet eens in de kleinste controller past.

[Sissors]

farlane schreef op zaterdag 10 januari 2015 @ 20:57:
Macro's ( "#define" ) worden vaak tijdens compileren als compiler/linker optie meegegeven ( -D optie in GCC ) en worden op die manier aan alle compilatieunits meegegeven.

Vergeten erbij te melden, die optie is helaas niet mogelijk omdat veruit de meeste gebruikers een online compiler gebruiken waarbij dat niet mogelijk is. Het is verder niet precompiled, dus dat is geen probleem.

[ Voor 6% gewijzigd door Sissors op 10-01-2015 21:15 ]

[farlane]

Dan is het het handigst denk ik om een speciale header te *leveren* en gebruiken voor user opties, die de user zelf kan aanpassen, maar die wordt geinclude door jouw library ( bijvoorbeeld lwIP doet het op die manier ).

[Sissors]

Klopt die heeft een config file erbij zitten. Die oplossing heeft dus als nadeel dat gezien ik dan onderdeel moet maken van de repository, verandering eraan betekend dat de lokale niet meer in sync is met de officiele.

Maar goed, iig bedankt voor de ideeën .

[PrisonerOfPain]

Sissors schreef op zaterdag 10 januari 2015 @ 21:46:
Klopt die heeft een config file erbij zitten. Die oplossing heeft dus als nadeel dat gezien ik dan onderdeel moet maken van de repository, verandering eraan betekend dat de lokale niet meer in sync is met de officiele.

Maar goed, iig bedankt voor de ideeën .

Niet perse - je kunt blijvoorbeeld al jou default config mee-leveren en iedere #define omringen met een #ifdef. Vervolgens kan je client dan de settings overriden met z'n eigen defines.

[Sissors]

Maar hoe zorg je er dan voor dat die client settings op een juiste manier bij de config file aankomen? Want als je ze gewoon bijvoorbeeld in main.cpp definieert dan is dat niet het geval zover ik weet. En als je de default config zelf moet wijzigen kom je weer op het vorige probleem uit.

[.oisyn]

Wellicht ten overvloede, maar een library is typisch niets meer dan een verzameling van object files (gecompileerde source files), en die object files in een library waar geen dependencies naar zijn worden standaard ook niet meegelinkt. Sommige compilers ondersteunen daarnaast function-level linking, waarbij er per functie wordt gekeken of hij nodig is voor de executable.

GCC lijkt dat laatste niet te ondersteunen, maar ik vond wel dit. Je kan het ook handmatig doen door je functies zoveel mogelijk over verschillende source files uit te splitsen.

[ Voor 11% gewijzigd door .oisyn op 11-01-2015 00:20 ]

[Sissors]

In dit geval zijn ze dus niet precompiled, maar gewoon de losse source files.

[.oisyn]

Ah ik snap nu wat je bedoelt, "precompiled" betekent wat anders dan jij bedoelt . In de context van C en C++ gaat dat voornamelijk om precompiled headers (dan wordt de parse tree van include files opgeslagen en hoeft die niet elke keer opnieuw te worden opgebouwd bij het compilen elke sourcefile).

Maar goed, je kunt er altijd voor kiezen om er gewoon wél een library van te maken (wat verder niet impliceert dat je de source niet meelevert). Scheelt een hoop kopzorgen met #ifdefs

[ Voor 6% gewijzigd door .oisyn op 11-01-2015 15:31 ]

[Sissors]

Misverstandje van mij dan. Maar dan moet ik heb voor Cortex M0, M3, M4 en M4 met FPU compileren, en binnenkort ook nog voor M7 .

[ Voor 4% gewijzigd door Sissors op 11-01-2015 15:47 ]

[.oisyn]

Maar je kunt het toch opnemen in het build proces? Als de gebruiker van jouw sourcecode er gewoon eerst een library van maakt dan kan die gebruiker zijn binaries beperken tot een minimum

[Sissors]

Het wordt voor 95% gebruikt bij een online omgeving inclusief compiler. En ook wanneer hij offline wordt gebruikt is het idee dat je enkel op het import knopje hoeft te drukken. Oftewel tenzij ik nu iets verkeerds begrijp, blijft het het handigste als ik het in de code zelf kan oplossen, en niet dat er weer vervolgstappen nodig zijn door de gebruiker.

[BoringDay]

m.b.v. make files?

[Sissors]

Bij die compiler moet je het gewoon zien als klik compile, krijg binary file om MCU mee te programmeren. Alles qua source code kan, maar geen compiler opties. Anders had je ook gewoon de compiler wat globaal kunnen laten definieren.

[.oisyn]

Dat kan alleen als je met #define werkt en alle sourcefiles worden geinclude vanuit source files die je compileert. Wat jij wil is op geen enkele andere manier mogelijk.

[farlane]

Sissors schreef op zaterdag 10 januari 2015 @ 23:59:
Maar hoe zorg je er dan voor dat die client settings op een juiste manier bij de config file aankomen?

Je moet dus dan, net ls lwIP het doet, een "UserConfig.h" includen vanuit jouw library, die de gebruiker zelf moet definieren en waarin hij settings kan "overschrijven". Als de user deze file *niet* maakt, krijgt hij een foutmelding.

.oisyn schreef op zondag 11 januari 2015 @ 00:19:
Sommige compilers ondersteunen daarnaast function-level linking, waarbij er per functie wordt gekeken of hij nodig is voor de executable.

GCC lijkt dat laatste niet te ondersteunen, maar ik vond wel dit. Je kan het ook handmatig doen door je functies zoveel mogelijk over verschillende source files uit te splitsen.

Je kunt GCC inderdaad all functies in aparte sections laten onderbrengen met -ffunction-sections; ongebruikte sections worden niet meegelinked. ( Ik ga er vanuit dat de ARM compiler dit ook kan en misschien wel standaard aan heeft staan, aangezien dit een erg belangrijke optie is in m.n. embedded systemen )

.oisyn schreef op zondag 11 januari 2015 @ 15:31:
Ah ik snap nu wat je bedoelt, "precompiled" betekent wat anders dan jij bedoelt .

Die uitspraak kwam van mij eigenlijk: daarmee bedoelde ik binary libraries i.t.t. libraries die nog van source moeten worden gecompiled. Precompiled leek me wel een aardige term, maar is misschien niet helemaal handig.

[MSalters]

De compiler moet de secties aanmaken, het is de linker die secties moet elimineren. De problemen waar .oisyn naar verwees zitten 'm in die laatste fase. Historisch probleem: vroeger had GCC geen eigen linker, en volgens mij wordt er ook nu nog regelmatig gebruik gemaakt van native linkers. (GNU/Linux is uiteraard een uitzondering, die heeft uiteraard een GNU linker)