Portable Programmierung mit C und Makefiles

[-Nuke-]

Clang: Auf LLVM basierend, ursprünglich vor allem von Apple aus Ärger über die geringe Kooperationsbereitschaft der GCC-Entwickler und die GPLv3 ins Leben gerufen.

Wenn man bedenkt, dass Apple aktuell einen eigenen Fork von LLVM und Clang betreibt mit einem Misch-Masch aus verschiedenen Versionen mit eigener Versionsnummer (aktuell "LLVM Version 10") und auch noch ein anderes (älteres) LLVM IR Format benutzt, dann kann man rückblickend die GCC-Entwickler schon verstehen

 

[CrimsonKing]

Zum GCC noch mal:
Für Bitoperationen sollte man ihn lieber nicht nehmen, der verrechnet sich ...

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87248

 

[rubricanis]

Ich weigere mich (noch!) mit bitoperationen zu spielen! Scheint aber unter recht speziellen Bedingungen aufzutreten. Nicht dass ich das wirklich beurteilen könnte!

Ich denke so etwas gibt es abei allen Compilern immer mal wieder...

 

[CrimsonKing]

Nö, nur im GCC sehr oft.
GNU und Qualitätssicherung...

Bitoperationen sind schon prima. Spätestens, wenn du mal eine Liste von Booleans übergeben willst, überlegst du dir zweimal, ob du lieber eine Funktion mit zehn Parametern oder eine Bitmaske haben willst.

 

[rubricanis]

Dafür kann gccc = bit-literalen umgehen was ja auch sinnvoll ist. So verstehe selbst ich wie Maskierung funktioniert. Also doch -std=gnu99! :-)

 

[CrimsonKing]

Bei der Wahl zwischen Binärkonstanten und Richtigrechnen nehm' ich Richtigrechnen.

 

[rubricanis]

Wenn die Mittel beschränkt sind, muss man sich eben helfen! Manche Leute mögen so etwas!

 

[rubricanis]

Es ist schon erstaunlich welche Probleme man bekommt wenn man sich nur ein wenig von den vorgebahnten Wegen entfernt. Es sieht so aus als ob ich dank eines Artikel von Johannes Peter einen Weg gefunden habe ein Projekt sowohl mit gcc als auch clang unter win10 zum kompilieren zu bekommen. Der Trick dabei ist dass mingw64 unbedingt unter C:/mingw64 installiert sein muss da diese Adresse bei der clang binary die man herunterladen kann fest einkompilert ist. Wie intelligente Menschen sowas machen können erschließt sich mir nun wirklich nicht. Zudem war es notwendig win-bash und einige unix-tools herunterzuladen die ich dann alle zusammengeschmissen habe. Das ganze nicht wegen der bash, denn die ist praktisch unbenutzbar da sie noch nicht einmal Pfade mit \\ versteht (soviel zum Namen "win"-bash). Was aber gebraucht wird sind die unix tools.

Ich habe noch nicht viel getestet aber das sieht soweit ganz gut aus. Clang wirft jede Menge Warnungen aus die aus den VC header kommen. Aber ich denke dass ich das - wie unter C wohl üblich - mit einer Reihe von Makros aus der welt schaffen kann. Die Kehrseite sieht so aus dass gcc bei mingw64 nur in Versin 5.1 vorliegt, die aktuelle ist 8.1. Aber ich werde, zumindest unter windows, hauptsächlich clang benutzen. Auf anderen Platformen mag das anders sein. VC kann ich mir dann bis auf die von clang automatisch geladenen header und wohl auch libraries schenken.

Ich war schon nahe daran aufzugeben und zu rust zurückzukehren da mich diese rumpfrimelei wirklich genervt genervt hat. Aber da wäre ein dummes Gefühl übrig geblieben und das mag ich nicht. Wir werden sehen wie es weiter geht...

Interessant find ich auch dass mir C zunehmend besser gefällt, besser als mir C++ jemals gefallen hat. Klar kann man da einigen Mist machen, aber dem kann man mit ein wenig Umsicht und einer defensiven Programmierung gut aus dem Weg gehen. Dafür bekommt man aber ein hohes Maß ein Freiheit was nicht zu unterschätzen ist. Für Programmier-Beamte eher nicht geeignet! :-) <SCNR>

 

[rubricanis]

Kann mir jemand sagen warum (g)make hier mit einem "invalid option" abbricht?

CFLAGS := -std=gnu99
CFLAGS += -DNDEBUG

Die Werte werden dann an ein submake weitergereicht.

xxx:
    @${MAKE} --no-print-directory -f src/$@.make self=$@ cc=$(CC) cflags=$(CFLAGS)

Im submake habe ich z.Z. nur ein @echo "--> $(cflags)".

Das Beispiel ist natürlich vereinfacht. Das += steht normalerweise in einem conditional. Wenn ich das += auskommentiere funktioniert das.

 

[CrimsonKing]

Welches ist denn die "invalid option"? "-DNDEBUG"?

 

[rubricanis]

Das wird als Make-Fehler deklariert, nicht von CC. Aber ich denke ich bin dem auf der Spur. Offenbar kann man nicht mehrere Definitionen mit einer variablen an das Submake weitergeben. Dies funktioniert nämlich auch nicht:

CFLAGS := -std=c99 -DNDEBUG

Nicht weiter tragisch: Dann werde ich die generellen Variablen im Hauptmake definieren und muss die dann eben im Submake dem compiler die daraus abgeleiteten Variablen einzeln übergeben. Ärgerlich da mehr Schreibkram, aber machbar.

Falls du aber einen Weg weißt wie man eine Menge Flags an ein Submake weitergeben kann (s.o.) , lass es mich wissen. Make ist eine ziemliche ....<sach ich nich>.

 

[CrimsonKing]

Ist das GNU oder BSD make? Bei Variablen ist das schon ein Unterschied.

 

[rubricanis]

GNU, aber lass mal wenn die nicht sofort was einfällt, ich bekomme das hin. Bis zur nächsten Stolperfalle!

 

[Idefixx]

Die Kehrseite sieht so aus dass gcc bei mingw64 nur in Versin 5.1 vorliegt, die aktuelle ist 8.1.

Die neuste Version des MingW findest Du hier; runterladen und starten:
Installer MingW 8.1

 

[rubricanis]

@Idefixx Vielen Dank! Da wundere ich mich doch wo ich die andere Version herhabe. Wie auch immer: funktioniert, auch mit clang.

Es ist schon erstaunlich über was man da alles stolpern kann und stolpert! Ich hoffe doch dass es nicht nur an mir liegt.

 

[rubricanis]

Make funktioniert soweit gut, allerdings habe ich es bislanrg immer mit "make --always-make ..." aufgerufen. Jetzt geht es an die Abhängigkeiten und da scheine ich irgend etwas falsch zu machen oder falsch verstanden zu haben.

Ich habe make in 1 Makefile und 2 subfiles aufgeteilt, wovon eines ein Programm (prg.make) und das andere eine statisch zu linkende Lib (lib.make) generiert. Das Programm ist abhängig von der lib. Das sieht im Makefile z.Z folgendermaßen aus:

all: $(TARGETS)

prg: lib/lib.a
    @${MAKE} --no-print-directory -f src/$@.make self=$@ platform=$(PLATFORM)\
            cc=$(CC) std=$(STD) mode=$(MODE)

lib:
    @${MAKE} --no-print-directory -f src/$@.make self=$@ platform=$(PLATFORM)\
    cc=$(CC) std=$(STD) mode=$(MODE)

lib/lib.a: lib

Ich würde erwarten dass lib via lib/lib.a aufgerufen wird wenn lib/lib.a nicht (!) exestiert. Das ist aber nicht der Fall denn ich bekomme in prg.make nur die Fehlermeldung dass lib.a nicht vorhanden ist. Natürlich könnte ich in target lib/lib.a den Aufruf von lib in eine entsprechen Abfrage wrappen, aber das ist wohl nicht im Sinne des Erfinders, oder?

Was mache oder denke ich falsch. Kann mir da vielleicht jemand auf die Sprünge helfen?

Peter

 

[Idefixx]

@peter - vielleicht liegt es daran, daß "lib" zum Zeitpunkt des Aufrufs nicht gefunden wird. Als Beispiel ein C-Programm. Die Fehlermeldung kommt, weil die Funktion nicht vereinbart wurde - der Compiler findet sie nicht zum Zeitpunkt des Aufrufs.

#include<stdio.h>

int main(void)
{
  anzeigen();
  return(0);
}

anzeigen(void)
{
  printf("Hallo!");
}

 

[rubricanis]

@Idefixx Nöö, das hat damit nichts zu tun. Das ist ein make, kein c Problem. Ich habe inzwischen wohl ein dutzend verschiedene, z.T. abenteuerliche Lösungen ausprobiert aber keine funktioniert unter allen Umständen. Mag ja sein dass es da eine Lösung gibt, aber vielleicht bin ich einfach zu dumm dazu. Zunächst gebe ich es soweit auf, dann muss man eben das Makefile mit -B (aka --always-make) aufrufen. Ist zwar blöd, soll aber nur für dieses Projekt sein. (3 static libs). Diese ganze Make-Choose ist <sach ich nicht>. Das mag für kleinere Sachen oder auch große im unix Umfeld ok sein, eine generelle Lösung ist das nicht. Es wird Gründe geben warum für größere Sachen oft CMake verwendet wird.

 

[schorsch_76]

CMake ist nichts anderes als ein Generator für die jeweilige make Anwendung. Sei es sln Files für MSVC oder Gnu make. Um Make zu verstehen empfehle ich das Buch "Autotools: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool" [1]

[1] https://www.amazon.de/Autotools-Pra...UTF8&qid=1537163565&sr=8-1&keywords=autotools

 

[rubricanis]

Also, wir können diesen thread jetzt abschließen. Zwar habe ich nicht alle Ziele erreicht, aber ich habe eine Menge gelernt und das Ergebnis ist recht befriedigend. Immmerhin habe ich neben meiner (noch kleinen) zwei größere und komplexere Biblotheken compilieren können. Leider kann ich eine davon nicht verwerten da sie mir doch zu fragil erscheint. Auf clang [*] unter windows habe ich verzichtet. Nicht weil das allzu schwierig ist, sondern mir z.Z. zuviel Arbeit macht. Auch deshalb weil man eh mingw und einige unix utils braucht um damit arbeiten zu können. Dann kann man auchg gleich mingw gcc verwenden. Etwas Zeit hat es noch gebraucht die compiler- und linker flags von gcc richtig zu setzen was nicht ganz einfach ist. Irgendwann werde ich die noch für clang unter unix überprüfen müssen.

Jetzt habe ich ersteinmal Lust auf Programmieren unter C und werde dazu ggf.Fragen in einem anderen thread stellen. Kann mir evtl. jemand noch eine Forum oder eine mailing list nennen die sich ausschließlich mit C befaßt und wo ein ähnlich freundlicher Ton wie (meist) hier üblich ist.

[*] Das eigenständige clang, also nicht das in MSC integrierte.

 

[ralli]

Jetzt habe ich ersteinmal Lust auf Programmieren unter C und werde dazu ggf.Fragen in einem anderen thread stellen. Kann mir evtl. jemand noch eine Forum oder eine mailing list nennen die sich ausschließlich mit C befaßt und wo ein ähnlich freundlicher Ton wie (meist) hier üblich ist.

Moin Peter, ein reines C Forum kenne ich nicht, alles ist irgendwie gemischt. Aber dieses macht einen guten Eindruck (auf mich):

Coding-Board

Aber wahrscheinlich kennst Du es schon ....

Gruß

 

[rubricanis]

Ich amüsiere mich mal wieder über mich selbst! Da ich mich nach gui toolkits umgesehen habe, erscheint mir neben IUP GTK+ am besten geeignet. Um mir das genauer anzusehen mußte ich jetzt doch msy2 installieren und muss sagen, es gefällt mir wirklich gut. Man fühlt sich doch recht schnell "zu Hause", auch wenn pacman für mich etwas gewöhnungsbedürftig ist. Yamagi hat (mal wieder) recht!

Wenn ich das generierte Programm nach windows kopiere meldet sich windows und sagt mir welche dll fehlt. Wenn ich die dann dazu packe läuft das wie unter mys2. Natürlich macht auch clang keinerlei Probleme und ich kann von Win aus Sublime Text und auch den Explorer verwenden. Prima, es kann weiter gehen!

 

[Idefixx]

Jetzt habe ich ersteinmal Lust auf Programmieren unter C und werde dazu ggf.Fragen in einem anderen thread stellen. Kann mir evtl. jemand noch eine Forum oder eine mailing list nennen die sich ausschließlich mit C befaßt und wo ein ähnlich freundlicher Ton wie (meist) hier üblich ist.

Deutschsprachige Foren für C sind etwas trostlos (geworden). Hackerboard
Englischsprachig: C Programming

Ein hervorragendes Buch für C ist: C Programming a Modern Approach 2nd edition, K.N.King
Teuer: C Programming A Modern ...
Als PDF (nicht so teuer): C Programming A Modern ...

 

[Yamagi]

Da ich mich nach gui toolkits umgesehen habe, erscheint mir neben IUP GTK+ am besten geeignet. Um mir das genauer anzusehen

Für kleinere Anwendungen ist oft auch FLTK einen Blick wert: http://www.fltk.org/index.php Es hat von Haus genug Funktionen für die meisten Einsatzzwecke; läuft unter X11, Windows und OS X und es hat nur Abhängigkeiten, lässt sich außerdem wenn nötig statisch linken.

 

[ralli]

FLTK bringt auch eine kleine "IDE" namens FLUID mit, mit der man eine GUI und callbacks zusammenstellen kann. Ist allerdings etwas gewöhnungsbedürftig.