Wat doen deze "Make"(file) regels.

bprosman

Golden Member

Weet iemand wat deze regels doen in een Makefile ?

code:

$(BUILD_DIR)version.c: $(BUILD_DIR)tag
	git describe --tag --always --dirty | \
		sed 's/.*/const char* Version_GetGitVersion(void) { return "&"; }/' > $@

# Always regenerate the git version
.PHONY: $(BUILD_DIR)version.c
De jongere generatie loopt veel te vaak zijn PIC achterna.
EricP

mét CE

Met de onderste regel beginnen: .PHONY is een target wat altijd out-of-date is. Die moet dus altijd runnen als make runt.

Het heeft een dependency op version.c (maar doet verder niks).
Door die dependency moet version.c gemaakt gaan worden. Mooi, daar is een rule voor.
version.c heeft een dependency op 'tag' (is daar ook nog een rule voor? Of bestaat dat file gewoon?)

Vervolgens wordt er wat uit git gehaald en gepiped naar sed. '.*/' wordt gezocht. De output van sed wordt naar $@ ge-re-direct, hetgeen 'current target', zo je wilt version.c is. De inhoud is het stuk 'const...'. Feitelijk een function die een char pointer terug geeft naar de string die sed net uit de output van git gehaald heeft.

Da's de korte versie, zo even uit het hoofd. Makefiles bouwen uit het niks is een jaar of 5, 10 terug, dus het is wat stoffig...

bprosman

Golden Member

Met de onderste regel beginnen: .PHONY is een target wat altijd out-of-date is. Die moet dus altijd runnen als make runt.

Mooi , dan snap ik die :-)

Vervolgens wordt er wat uit git gehaald

Dat faalt met deze error, maar dat ligt aan mijn ontwikkelomgeving :

git describe --tag --always --dirty | \
sed 's/.*/const char* Version_GetGitVersion(void) { return "&"; }/' > build/version.c
fatal: not a git repository (or any parent up to mount point /mnt)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). :

File version.c zit niet in het package.
De compiler valt terug op deze code als version.c niet gevonden word :

// No version.c file generated for LPCXpresso builds, fall back to this
__attribute__((weak)) const char* Version_GetGitVersion(void) {
return "no version info";
}

Maar ik begrijp dat hij de versie info uit git trekt dan ?.

De jongere generatie loopt veel te vaak zijn PIC achterna.

Hij probeert de versie uit git te halen, maar jou copie is geen git repository.

code:

git init . 
git add Makefile
git commit -m "Git tevreden houden". 

Of het Makefile aanpassen en deze hele zooi weghalen. En even met de hand de version.c maken:

code:


const char* Version_GetGitVersion(void) { return "Geen git!"; }

Oh, ik zie nu de "weak" shit. Dan zou een lege "version.c" ook moeten werken.

Wat daarom ook zou moeten werken is het makefile aanpassen dat ie het niet erg vind als git gaat lopen zeuren zoals bij jou.

Als mijn kennis niet veroudert is... dan zou van

bla | blup

de returncode die van blup moeten zijn. Git kan zeuren, sed krijgt geen input en produceert geen output -> Het zou moeten werken. Je kan kijken of || true of && true er achter zetten helpt. 1 van de twee zou de returncode op "gelukt" moeten zetten. Maar als de boel zich niet aan de handleiding houdt weet je maar nooit of dat werkt.

[Bericht gewijzigd door rew op 9 januari 2022 21:37:11 (38%)]

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
EricP

mét CE

File version.c zit niet in het package.

Die moet daar ook niet in zitten. Die maak je ter plekke.

De compiler valt terug op deze code als version.c niet gevonden word :

// No version.c file generated for LPCXpresso builds, fall back to this
__attribute__((weak)) const char* Version_GetGitVersion(void) {
return "no version info";
}

Best netjes opgelost...

Maar ik begrijp dat hij de versie info uit git trekt dan ?.

Inderdaad. Dat is waarschijnlijk de makkelijkste manier om een 'versie' te krijgen die altijd parallel loopt aan het label. Al is het ff trucen.
Vroegah, heel lang geleden, had ik er wat csh scriptjes voor - niet voor git, maar voor het daar gebruikte versiebeheergebeuren. Nog niet handig genoeg om het volledig in makefiles op te lossen. Het concept wat niet anders: maak een file wat bij de uiteindelijke build mee gaat. Ik meen dat wij het destijds (voor het C-stuk) met defines in header files oplosten. Maar het concept is niet anders. Waar je in csh de versie nodig had, werd die weer uit het eerder gegenereerde header file ge-grep-ed (en daarna wat gestript om alleen over te houden wat nodig was). Het was wel erg prettig dat wanneer er 'gezeik' uit het veld kwam, je aan 'versie' in 'help' ofzo genoeg had om exact dat wat daar stond ff te reproduceren (de fix met branches enzo was een ander paar mouwen, maar goed...).

Krijg dat git stuk op de rit en het werkt. En je zou natuurlijk heel erg lomp dat git/sed stuk er gewoon uit kunnen halen en iets met 'echo <functie gedoe> return("Doet het niet");' ofzo.

Zet gewon een - teken voor het git commando, dan wordt de foutmelding ignored.
LET op dat je de TAB laat staan anders werkt je makefile niet meer.
<TAB>-git .blabla..
dus.

Henri's Law 1: De wet van behoud van ellende. Law 2: Ellende komt nooit alleen.

Ohja vergeten te melden: dat ignore foutmelding kan ook, maar ik weet n8et uit mijn hoofd hoe dat moet. Nog steeds niet, want op CO wordt een font gebruikt waarbij twee tekens te veel op mekaar lijken...

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/