Makefile vereinfachen (Cython)

[Dennis S. (eltio)]

Guten Morgen zusammen,

ich möchte mit Cython und GCC Python-Code in eine ausführbare Datei zu 
übersetzen und dies mit einem Makefile zu automatisieren. Das 
Dummyprojekt besteht aus der "Main"-Datei app.py und den Modulen add.py 
und sub.py. Hier mein aktueller Stand:

CC = gcc
INC = /usr/include/python3.5m
LIBS = -l python3.5m
OBJECTS = add.c sub.c app.c
CFLAGS = -O3

app: $(OBJECTS)
  $(CC) $(OBJECTS) -o $@ $(CFLAGS) -I $(INC) $(LIBS)

add.c: add.py
  cython add.py

sub.c: sub.py
  cython sub.py

app.c: app.py
  cython --embed app.py

clean:
  rm *.c

Die Datei app.py muss wegen des --embed-Parameters im Cython-Aufruf 
gesondert behandelt werden. Alle andere Dateien jedoch nicht. Wie kann 
ich dies elegant in dem Makefile abbilden?

Wünschenswert wäre natürlich noch die rekursive Abarbeitung und das 
Ersetzen der Dateiliste durch eine Variable oder so. Aber ich denke da 
werde ich was finden.

Gruß und Dank
Dennis

[Wilhelm M. (wimalopaan)]

Bei GNU-make kann man target-specific flags setzen.

Du schreibst eine allg. Regel für .c -> .py, in der Du die Variable 
bspw. EXTRAFLAGS verwendest.

Und für das target app.c

app.c: EXTRAFLAGS += --embed

[Dennis S. (eltio)]

Cool, vielen Dank für den Hinweis. Falls es jemanden interessiert hier 
die aktuelle Version mit dem Tip von Wilhelm M. und dem automatischem 
Auflisten der Python-Codes. Fehlt nur noch die rekursive Version:

CC = gcc
INC = /usr/include/python3.5m
LIBS = -l python3.5m
OBJECTS = $(patsubst %.py,%.c,$(wildcard *.py))
CFLAGS = -O3

app: $(OBJECTS)
  $(CC) $(OBJECTS) -o $@ $(CFLAGS) -I $(INC) $(LIBS)

%.c: %.py
  cython $(EXTRAFLAGS) $<

app.c: EXTRAFLAGS += --embed

clean:
  rm *.c

[Wilhelm M. (wimalopaan)]

Was meinst Du genau mit rekursivem Abarbeiten? In vielen directories?

[Dennis S. (eltio)]

Wilhelm M. schrieb:
> Was meinst Du genau mit rekursivem Abarbeiten? In vielen
> directories?

Naja, ein "echtes" Python-Projekt ist ja etwas umfangreicher. Da wäre 
die Ordnerstruktur beispielsweise:

Modul1
--mod1.py
Module2
--mod2.py
app.py

Es gibt also auch Quellcodes in Unterordnern die mit einbezogen werden 
müssen. Ich habe jetzt folgende Lösung die zu funktionieren scheint, 
aber vielleicht habe ich etwas wichtiges übersehen:

CC = gcc
INC = /usr/include/python3.5m
LIBS = -l python3.5m
OBJECTS = $(patsubst %.py,%.c,$(shell find . -name '*.py'))
CFLAGS = -O3

app: $(OBJECTS)
  $(CC) $(OBJECTS) -o $@ $(CFLAGS) -I $(INC) $(LIBS)

%.c: %.py
  cython $(EXTRAFLAGS) $<

app.c: EXTRAFLAGS += --embed

clean:
  rm *.c

Gruß
Dennis

[Markus F. (mfro)]

Dennis S. schrieb:
> OBJECTS = $(patsubst %.py,%.c,$(shell find . -name '*.py'))

Den unbedarften Leser irritiert möglicherweise, daß hier nicht drin ist, 
was draufsteht: $(OBJECTS) sind gar keine OBJECTS (und jetzt hast Du das 
gegenüber deiner ersten Version auch noch gut versteckt).

Ich jedenfalls würde davon ausgehen, daß in einer Variablen mit dem 
Namen nur *.o-Dateien drin sein können.

Darüber hinaus: das $(shell find ...) kann man machen, muß man aber 
nicht. Wenn Du dir irgendeine "unbedarfte" Python-Datei (die mit deinem 
Projekt gar nichts zu tun hat, z.B. zum Vergleich) in deine 
Verzeichnisstruktur kopierst, erlebst Du möglicherweise eine 
Überraschung.

[Dennis S. (eltio)]

@Markus F.:

Du hast mit beiden Punkten Recht. Ich habe den Variablennamen geändert. 
Aber die zweite Anmerkung ignoriere ich erstmal gekonnt für dieses 
Projekt... ;-)

[I <3 Makefiles (Gast)]

>> Darüber hinaus: das $(shell find ...) kann man machen, muß man aber nicht.
>> Wenn Du dir irgendeine "unbedarfte" Python-Datei (die mit deinem Projekt gar
>> nichts zu tun hat, z.B. zum Vergleich) in deine Verzeichnisstruktur kopierst,
>> erlebst Du möglicherweise eine Überraschung.

> Du hast mit beiden Punkten Recht. Ich habe den Variablennamen geändert.
> Aber die zweite Anmerkung ignoriere ich erstmal gekonnt für dieses
> Projekt... ;-)

So sehr dieses "Sammeln per Globbing" aus programmatischer Sicht 
attraktiv weil "algorithmisch" und konzis erscheint, es ist ein No-Go.

Bedienen wir uns der Analogie dass ein Makefile wie ein Kochrezept 
wirkt, so bedeutet obige Zeile das als Kochzutaten "alles was Rot ist" 
und gerade auf der Küchenarbeitsfläche herumliegt ins Gericht kommt. Die 
Warnung von Markus weist darauf hin das eventuell Paprika- und 
Karottenabschnitte im Kirschkuchen landen können.

Gute Makefiles listen die Projekt"Zutaten" explizit und abschliessend 
auf; ja das verpflichtet zur Pflege. Das erlaubt aber auch 
(plausibilitäts-)Kontrolle.

Globbing ist nützlich zur Selektion von Teilmengen.

Eine alternative Herangehensweise könnte sein, dass im Makefile ein 
neues, leeres Arbeitsverzeichnis erstellt wird und z.B. aus einem 
SourcecodeRepo (git, svn, ...) mit den "Zutaten bestückt" wird.

[Dennis S. (eltio)]

I <3 Makefiles schrieb:
> Bedienen wir uns der Analogie dass ein Makefile wie ein Kochrezept
> wirkt, so bedeutet obige Zeile das als Kochzutaten "alles was Rot ist"
> und gerade auf der Küchenarbeitsfläche herumliegt ins Gericht kommt. Die
> Warnung von Markus weist darauf hin das eventuell Paprika- und
> Karottenabschnitte im Kirschkuchen landen können.
Eine nette Analogie. Aber konkreter steht da ja "alles was .py" ist, 
wird verarbeitet. Und das ist in diesem Fall absolut korrekt.

> Gute Makefiles listen die Projekt"Zutaten" explizit und abschliessend
> auf; ja das verpflichtet zur Pflege. Das erlaubt aber auch
> (plausibilitäts-)Kontrolle.
Ich wollte gerade rummäkeln... aber ja, der Linux-Kernel macht dies in 
der Tat so.

> Eine alternative Herangehensweise könnte sein, dass im Makefile ein
> neues, leeres Arbeitsverzeichnis erstellt wird und z.B. aus einem
> SourcecodeRepo (git, svn, ...) mit den "Zutaten bestückt" wird.
Das ist hier der Fall. Das ganze wird mit einem VCS verwaltet.

Ich danke dir für deine Anmerkung. Ich denke drüber nach, allerdings 
habe ich das Gefühl, dass die Bequemlichkeit vorerst siegen wird...

Gruß
Dennis

[Bernd K. (prof7bit)]

I <3 Makefiles schrieb:
> So sehr dieses "Sammeln per Globbing" aus programmatischer Sicht
> attraktiv weil "algorithmisch" und konzis erscheint, es ist ein No-Go.

Das ist Geschmackssache. Der Pragmatiker verwendet Ordner um 
zusammengehörige Dateien zu gruppieren und Dateinamenerweiterungen um 
ihren Dateityp zu kennzeichnen. Anstatt Listen dafür zu führen verwendet 
er einfach die ohnehin vorhandenen Mechanismen des Dateisystems.

> Bedienen wir uns der Analogie dass ein Makefile wie ein Kochrezept
> wirkt, so bedeutet obige Zeile das als Kochzutaten "alles was Rot ist"
> und gerade auf der Küchenarbeitsfläche herumliegt ins Gericht kommt.

genausogut kann man vereinbaren daß alles was in den Schüsseln die mit 
"Zutaten/Kirschkuchen" und der Schüssel "Zutaten/Kuchen" beschriftet ist 
in den Kirschkuchen gelinkt wird. Egal was es ist. Es ist ja nicht so 
daß die Zutaten lustig auf dem Tisch herumspringen wenn gerade mal 
keiner hinschaut und von selbst in diese Schüsseln hüpfen. Man kann 
problemlos vereinbaren daß nichts in der Schüssel sich ohne guten Grund 
dort befindet.

Dann muss man auch nicht dauernd am Makefile herumschrauben wenn man mal 
eine Datei umbenennt oder eine neue hinzukommt, man wirft sie einfach in 
den richtigen Ordner. Die Anwesenheit oder Abwesenheit einer Datei in 
einem bestimmten Ordner ist exakt genauso explizit wie das 
Aufschreiben ihres Namens in einer Liste, kein bisschen weniger und auch 
kein bisschen mehr.