Hallo zusammen,
ich wollte mal nachhören, wer makefiles benutzt bzw sie selbst erstellt.
Aktuell haben unsere Projekte ca. 150 .c und .h Files. Als
Entwicklungsumgebung wird Codeblocks genutzt, das ja ein Projektfile
erzeugt. In diesem Projektfile stehen ja quasi die Informationen drin,
die auch ins makefile gehören. Daher wäre nun mein Ansatz ein makefile
zu schreiben und dann ist man ja frei von Entwicklungsumgebung,
Betriebssystem... Natürlich hat man Anfang mal etwas Aufwand um das
makefile zu erstllen.
Wie sieht das bei euch aus? Setzt ihr auch komplett auf eine
Entwicklungsumgebung oder doch eher auf makefiles und dann kann jeder
Entwickler machen was er will?
Mir ist durchaus bewusst, dass beides so seine Vor- und Nachteile hat.
Gruß Chris
Chris schrieb:> und dann kann jeder Entwickler machen was er will?
Ich glaube du hast noch nie in einer Firma mit mehr als 3 Entwickler
gearbeitet.
Chris schrieb:> Setzt ihr auch komplett auf eine Entwicklungsumgebung
Du hast auch noch nie Software für mehrere Betriebssysteme / Datenbanken
etc. entwickelt.
Wie automatisierst du ohne Makefile(s) die Produktgenerierung in
Anhängigkeit einer Versionsverwaltung mit unterschiedlichen
Versionsständen, Branches?
Natürlich läuft sowas über make bzw. make ähnliche Tools.
Hallo Chris,
zur Zeit benötige ich bei meinem jetzigen AG keine Makefiles.
Davor nutzten wir massiv make & Makefiles, um unsere nächtlichen Builds
zu generieren - ca. 10 Subsysteme, Unmengen an .h, .c & .cpp--Dateien.
Müsste ich wieder damit anfangen, würde ich den Einsatz von CMake
erwägen/bevorzugen. Lernkurve ist aber steil.
Du bist dadurch von IDE's unabhängig, kann alles in CMkakeLists.txt
abgebildet wird.
Jeder Programmierer/Entwickler kann dann dann die IDE/den Editor seiner
Wahl benutzen, beeinträchtigt die Builds nicht.
mfg
Olaf
Ich benutze zur Entwicklung Eclipse mit dem erzeugten project file.
Spätestens wenn es aber ans release geht, wird cmake eingesetzt.
Einerseits bekommt man nochmals einen Überblick über das Projekt und
findet dateileichen, andererseits wird man frei von der IDE, so dass
kompilieren auf verschiedenen Rechnern und Betriebssystemen möglich ist
(rein theoretisch, da der Compiler sich ändern kann)
Die Lernkurve fand ich übrigens nicht steil, ich hab das selbständig an
einem Tag "migriert" und seitdem parallel zum Eclipse im Einsatz.
Ob das der richtige Weg ist bezweifle ich aber noch ein bisschen, da
sich eclipse settings von den cmake unterscheiden können.
Cmake kann auch Eclipse project files erzeugen, bei mir hat das aber nie
funktioniert, vermutlich mache ich das falsch.
Makefiles finde ich dagegen sehr unleserlich, ähnlich zu gewissen
#define Schlachten in Libs. Ist aber Ansichts- und Übungssache.
Chris schrieb:> Setzt ihr auch komplett auf eine> Entwicklungsumgebung oder doch eher auf makefiles
Ja. Eine vollständige Entwicklungsumgebnung hat ja in der Regel einen
eigenen Make-Mechanismus, der nicht unbedingt auf einem dedizierten
Makefile beruht. Da mache ich mir nicht die Mühe, noch ein Makefile zu
erstellen, sofern das überhaupt geht bzw. ausgewertet wird, weil ich mir
ja nicht die doppelte Arbeit machen will.
Hat man Compiler und Linker ohne IDE, braucht man natürlich ein
Makefile, besonders dann, wenn man Mixed Language Projekte hat, z.B. C,
Pascal und Assembler. Das ist aber deutlich ausser Mode gekommen.
Georg
Operator S. schrieb:> Die Lernkurve fand ich übrigens nicht steil, ich hab das selbständig an> einem Tag "migriert" und seitdem parallel zum Eclipse im Einsatz.
Beim Einsatz der meistens verwendeten Compiler - GCC, MinGW, MSVC, .. -
gebe ich Dir recht.
Ich nutze das Ganze aber mittels Toolchain & Cross-Compiler, da ist das
etwas komplexer - verschiedene MCU's, Compiler, Avrdude, JTAG, ...
Macht - mir - aber Spaß. ;-))
mfg
Olaf
Der Andere schrieb:> Ich glaube du hast noch nie in einer Firma mit mehr als 3 Entwickler> gearbeitet.
Stell dir vor, wir arbeiten sogar mit 5 Entwicklern an einem Projekt.
Lass deine Kommentare bitt sein!
Georg schrieb:> Ja. Eine vollständige Entwicklungsumgebnung hat ja in der Regel einen> eigenen Make-Mechanismus, der nicht unbedingt auf einem dedizierten> Makefile beruht. Da mache ich mir nicht die Mühe, noch ein Makefile zu> erstellen, sofern das überhaupt geht bzw. ausgewertet wird, weil ich mir> ja nicht die doppelte Arbeit machen will.
Ja genau, aber dann muss auch jeder die gleiche Umgebung verwenden und
da fängt es schon an. Einer editiert mit Notepad, der Andere nutzt
Codeblocks, da es vom Steuergeräteherstelle verwendet wird und der dann
auch bei Problem unterstützen kann. Der Nächste nutzt dann Eclipse, da
es dafür eine GIT Anbindung gibt. Daher kam ich dann dazu mich mit den
makefiles zu beschäftigen, da dort ja auch die Compilereinstellungen
hinterlegt sind.
Es sind halt 2 Dinge, die ich mit dem makefile erschlagen kann. Jeder
nutzt die gleichen Compilereinstellungen und man ist unabhängig von der
Entwicklungsumgebung.
Chris schrieb:> Stell dir vor, wir arbeiten sogar mit 5 Entwicklern an einem Projekt.> Lass deine Kommentare bitt sein!
Und jeder macht was er will?
Nein ich lasse meine Kommentare nicht sein, ich kann nur nicht glauben,
dass Anarchie in einer Entwicklungsabteilung > 5 Mann herrscht.
Ansonsten sind ja die wichtigen Gründe genannt worden:
- unterschiedliche Zielsysteme
- einheitliche compiler/linker Settings
- automatische Release Generierung
- Sourceverwaltung mit unterstützung unterschiedlicher Releases Patch
branches
Und jetzt sag du dass ihr das in eurer Firma alles nicht braucht,
sondern die Produktreleases einfach mal von dem oder jenem
Entwicklerrechner gezogen werden, dann:
Chris schrieb:> und dann kann jeder Entwickler machen was er will?
Vieleicht hatte ich dich ja einfach falsch verstanden.
Die *.c Dateien compilieren und linken wir mit der eclipse-IDE. Einen
Teil der dafür benötigten *.h Dateien erzeugen wir über eigene Tools mit
Hilfe von gmake, welches wir als abhängiges pre-project in eclipse
einbinden. Ebenso als post-make zum erzeugen von weiteren outputs wie
Hex-Dateien und Tabellen.
Es macht durchaus Sinn zu kombinieren.
cmake ist sehr flexibel und mächtig. Die Sprache ist ein bisschen
strange aber es funktioniert auch gut wenn man nicht jedes Detail genau
versteht grins
Micro schrieb:> Es macht durchaus Sinn zu kombinieren.
Sehe ich genauso.
Man sucht sich die Tools heraus, die man für sein Projekt benötigt und
kombiniert diese geschickt.
Nicht mehr, nicht weniger.
Spielt man aber als Team, empfehlen sich einfach einige Tools:
- Git
- CMake
- GCC
- Doxygen
- ...
Das kristallisiert sich aber von selbst heraus, könnte man auch als
Quasi-Standard sehen. ;-))
mfg
Olaf
Hallo, darf man mal erfahren in welcher Branche ihr soetwas anwendet?
Also ich darf damit leider im Sicherheitsbereich nicht mit arbeiten.
Soll jetzt keine kritik sein, mich interessiert es einfach nur, Danke.
Ist für mich einfach nur interessant für welchen Umfang welche Lösungen
in Frage kommen.
Gruß Sascha
Sascha schrieb:> Also ich darf damit leider im Sicherheitsbereich nicht mit arbeiten.
Wie meinst du das? Sowas wie Versionsverwaltungen oder Makefiles erhöhen
doch anerkanntermassen die Sicherheit gegen Fehler bei der Entwicklung,
drauf zu verzichten wäre total unsinnig.
Glaubst du oder dein Chef wirklich ernsthaft, alles manuell und ohne
Computerunterstützung zu machen wäre wirklich SICHER?
Georg
Hallo,
nein Georg, darum gehts dabei gar nicht, sondern die Tools sollten
zertifiziert sein. Aber das Problem endet bei mir schon früher nehmlich
schon beim GCC Compiler und Assembler bzw. bei den Libs.
Deshalb würde mich das einmal interessieren, ob jemand im
Sicherheitsbereich mit dem GCC Compiler arbeitet. Vor allem im Embedded
bereich.
Gruß Sascha
Sascha schrieb:> Deshalb würde mich das einmal interessieren, ob jemand im> Sicherheitsbereich mit dem GCC Compiler arbeitet.
Jain! In einem vorherigen Projekt haben wir SW entwickelt nach ISO
26262.
Da wir von dem zertifizierten Compiler aber zu wenig Lizenzen hatten,
haben die Entwickler in der tagtägliche Arbeit GCC eingesetzt und nur
für Release-builds und Debuggen am Target den lizenzierte Compiler.
Meiner Meinung nach wäre es sinnvoller gewesen mehr Lizenzen zu
beschaffen, anstatt zwei Toolketten zu betreuen, aber das ist eine
andere Diskussion ;-)
Operator S. schrieb:> Cmake kann auch Eclipse project files erzeugen
Eclipse kann auch mit existierenden Makefiles arbeiten und kann sich
anhand dessen Konsolenausgaben automatisch selbst konfigurieren (-I, -D,
etc.).
Ich verwende kleine übersichtliche handgeschriebene Makefiles und stelle
sicher daß alles jederzeit auf der blanken Konsole gebaut werden kann
und in Eclipse benutze ich dann oben genannten Mechanismus um das
Projekt in Eclipse mit ein paar Mausklicks zu importieren. Das geht
recht zügig wenn man den Dreh erst mal raus hat.
Die Belohnung dafür ist die vollständige Kontrolle, vollständiges
Verständnis und vollständige Reproduzierbarkeit des ganzen
Build-Vorgangs.
Olaf B. schrieb:> Spielt man aber als Team, empfehlen sich einfach einige Tools:> - Git> - CMake> - GCC> - Doxygen> - ...>> Das kristallisiert sich aber von selbst heraus, könnte man auch als> Quasi-Standard sehen. ;-))
Bis auf CMake wenden wir diese Tools an. Ich glaube ich versuch mich mal
an einem makefile und dann sehe ich ja den Aufwand und Nutzen davon.
Sascha schrieb:> Deshalb würde mich das einmal interessieren, ob jemand im> Sicherheitsbereich mit dem GCC Compiler arbeitet. Vor allem im Embedded> bereich.
Was meinst du genau mit Sicherheitsbereich?
Ich arbeite in der Landmaschinenbranche und hier ist Funktionale
Sicherheit ein großes Thema.
Und das mit der Zertifizierung ist so eine Sache. Ein bekannter ist
Teamleiter Software im Avionikbereich. Da muss theoretisch jede Zeile
Code geprüft und getestet werden aber soetwas klappt in der Realität
nicht, da auch Linux als OS auf manchen Steuergeräten läuft.
Ich habe keine Erfahrungen mit make-files, daher auch meine Frage als
Querleser: sind die make-files an Betriebssystem gebunden? Oder kann ich
das selbe File auch auf Linux und Windows System genutzt werden?
Ich hab bisher immer nur ne IDE genommen, die mir dann alles abgenommen
hat...
Eric B. schrieb:> Kentnisse> ^ Steil -> Viel gelernt in wenig Zeit = einfach> | /> | /> | /> | / ___--- Flach -> Wenig gelernt in viel Zeit = schwierig> |/___---> +-------------> Zeit
Hab ich irgendwie nie verstanden. Warum ist es leichter, wenn man in
wenig Zeit viel lernen muss, als wenn man nur wenig lernen muß?
Eric B. schrieb:> Meiner Meinung nach wäre es sinnvoller gewesen mehr Lizenzen zu> beschaffen, anstatt zwei Toolketten zu betreuen, aber das ist eine> andere Diskussion ;-)
Wobei ja die Nutzung von zwei Compilern die Sicherheit des Code durchaus
noch erhöhen kann, weil man mit dem einen ggf. noch Fehler findet, die
auf dem anderen Compiler nicht gleich auffallen.
Chris schrieb:> Was meinst du genau mit Sicherheitsbereich?> Ich arbeite in der Landmaschinenbranche und hier ist Funktionale> Sicherheit ein großes Thema.>> Und das mit der Zertifizierung ist so eine Sache. Ein bekannter ist> Teamleiter Software im Avionikbereich. Da muss theoretisch jede Zeile> Code geprüft und getestet werden aber soetwas klappt in der Realität> nicht, da auch Linux als OS auf manchen Steuergeräten läuft.
Deshalb gibt es unterschiedliche Sicherheitslevel. Im Fahrzeug siehe
z.B. ASIL. Ein Entertainment-System kann damit ganz andere
Sicherheitsanforderungen haben als das ESP - oder es kann sich gar
zwischen dem Teil im Entertainment-System, der die Buskommunikation
macht und dem, der die eigentliche Funktion umsetzt (auf dem dann auch
ein Betriebssystem läuft), unterschieden werden.
Je nach Anforderung kann es auch sein, daß nicht nur an dein Programm,
sondern auch an die Tools mit denen es erstellt und getestet wird,
bestimmte Anforderungen gestellt werden. Dann müssen diese
dementsprechend zertifiziert sein. Die sind dann auch entsprechend
teuer. Mit gcc geht das dann eher nicht, weil keiner die Kosten auf sich
nimmt, den fit für die Zertifizierung zu machen und diese dann
durchzuführen, nur um den Compiler dann kostenlos zu verteilen.
ASIL-D ist mit dem GCC machbar
Für eine reproduzierbare SW-Ablieferung ist ein make unerlässlich
zumal da noch einige mehr Tools zum Compiler dazukommen.
Auf fremde Libs muss man aber bei höheren Sicherheitsanforderungen
verzichten.
Mario schrieb:> sind die make-files an Betriebssystem gebunden? Oder kann ich> das selbe File auch auf Linux und Windows System genutzt werden?
make/gmake läuft auf sehr vielen Betriebssystemen.
Wenn man mal davon absieht, dass es mit "\" und "/" in Pfadnamen mal
schwierigkeiten geben kann, lässt sich eine Make-Skript in der Regel
recht leicht portieren.
Rolf M. schrieb:> Eric B. schrieb:>> Kentnisse>> ^ Steil -> Viel gelernt in wenig Zeit = einfach>> | />> | />> | />> | / ___--- Flach -> Wenig gelernt in viel Zeit = schwierig>> |/___--->> +-------------> Zeit>> Hab ich irgendwie nie verstanden. Warum ist es leichter, wenn man in> wenig Zeit viel lernen muss, als wenn man nur wenig lernen muß?
Niemand zwingt dich, also ist es kein muß. Ich habe das immer so
interpretiert dass man in wenig Zeit viel lernen kann.
Eric B. schrieb:> Rolf M. schrieb:>> Eric B. schrieb:>>> Kentnisse>>> ^ Steil -> Viel gelernt in wenig Zeit = einfach>>> | />>> | />>> | />>> | / ___--- Flach -> Wenig gelernt in viel Zeit = schwierig>>> |/___--->>> +-------------> Zeit>> Hab ich irgendwie nie verstanden. Warum ist es leichter, wenn man in>> wenig Zeit viel lernen muss, als wenn man nur wenig lernen muß?>> Niemand zwingt dich, also ist es kein muß. Ich habe das immer so> interpretiert dass man in wenig Zeit viel lernen kann.
Kommt drauf an ob man das gelernte gegen Zeit aufträgt (steil= man kann
schnell viel lernen) oder gegen Fortschritt mit dem Tool (steil= man
muss viel lernen, um es sinnvoll benutzen zu können)
Im ersten Fall ist steil gut, im zweiten wird es komplizierter. Soll es
einfach nur funktionieren, ist flach dann besser. Will man lernen oder
sucht die Herausforderung hingegen ist steil auch bei zweitem gut.
Martin schrieb:> Mario schrieb:>> sind die make-files an Betriebssystem gebunden? Oder kann ich>> das selbe File auch auf Linux und Windows System genutzt werden?>> make/gmake läuft auf sehr vielen Betriebssystemen.> Wenn man mal davon absieht, dass es mit "\" und "/" in Pfadnamen mal> schwierigkeiten geben kann, lässt sich eine Make-Skript in der Regel> recht leicht portieren.
Kommt drauf an. In Makefiles werden ja auch gerne mal verschiedene
Shell-Tools benutzt, die man dann auf der Zielplattform auch haben muss
oder für die man sich einen Ersatz suchen muss.
Jan H. schrieb:> oder gegen Fortschritt mit dem Tool (steil= man muss viel lernen, um es> sinnvoll benutzen zu können)
Das entspricht eher so meinem Verständnis: Wenn ich erstmal viel
Einarbeitung brauche, um ein System überhaupt mal einigermaßen benutzen
zu können, habe ich anfangs eine steile Lernkurve. Wenn es dagegen sehr
intuitiv zu bedienen ist und man sich dann auch im Laufe der weiteren
Benutzung langsam das Detailwissen darüber aneignen kann, ist die
Lernkurve flach.
Eric B. schrieb:> Niemand zwingt dich, also ist es kein muß. Ich habe das immer so> interpretiert dass man in wenig Zeit viel lernen kann.
Für mich ist allerdings lernen = Arbeit bzw Aufwand. Viel lernen heißt
also viel Aufwand.
Uuups, da hatte ich das wohl auch falsch im Kopf. Hatte die Lernkurve
immer mit einem Weg assoziert, während steil ein beschwerlicher Weg
beschrieb und flach ein gemütlicher Spaziergang.
Um es allgemeinverständlich auszudrücken: Ich fand cmake einfach zu
erlernen ;-)
