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.
Wir verwenden ausschließlich cmake. Macht vieles entspannter. Grüsse, René
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.
Olaf B. schrieb: > Lernkurve ist aber steil. Das heisst, ist einfach zu lernen?
1 | Kentnisse
|
2 | ^ Steil -> Viel gelernt in wenig Zeit = einfach |
3 | | / |
4 | | / |
5 | | / |
6 | | / ___--- Flach -> Wenig gelernt in viel Zeit = schwierig |
7 | |/___--- |
8 | +-------------> Zeit |
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 ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.