Ich suche Hilfe für mein Projekt makefiles zu generieren um es außerhalb der IDE zu übersetzen und zu installieren. Bisher hatte ich damit wenig zu tun da ich ursprünglich aus dem embed Bereich komme. Nun habe ich mich an autotools versucht und auch bei einfachen Beispielen Erfolg. Doch das Thema ist doch zu komplex um schnelle Lösungen zu erzeugen und das Projekt doch etwas komplexer als solche Beispiele. Kann mir dabei jemand behilflich sein ? Bevor man es teilt sollte es sich auch außerhalb der IDE übersetzen lassen ;). Der Name erscheint auch in der Heldenliste :)... Es steht auf meiner Agenda mich damit zu befassen...
Marco H. schrieb: > Ich suche Hilfe für mein Projekt makefiles zu generieren um es außerhalb > der IDE zu übersetzen und zu installieren. > > Bisher hatte ich damit wenig zu tun da ich ursprünglich aus dem embed > Bereich komme. Nun habe ich mich an autotools versucht und auch bei > einfachen Beispielen Erfolg. Die autotools sind heute nicht mehr so gängig. Am häufigsten dürfte heute cmake zum Einsatz kommen. Das hat inzwischen auch recht gute Einbindung in gängige IDEs, so dass man es dann nicht nur ohne, sondern auch mit IDE gut nutzen kann.
genau :).. du kannst ohne Probleme make in Debug Ordner aufrufen und das Projekt wird gebaut. Aber eben nur auf der Maschine und im dem Pfad. Das ist ja die Aufgabe von autotools und cmake etc. das makefile so zu basteln das alles zum bauen vorhanden ist. Mit eclipse gibt es dann ein Problem wenn im Nachhinein einfällt das man daraus ein autotools Projekt machen will. Die cmake Plug-ins habe ich mir angeschaut und ich blick da nicht durch... für das Nachhinein umwandeln sind diese wohl nicht zu gebrauchen.. Ich habe zwei gute Bücher im Schrank :) "The GNU make book" und "autotools".. Das dauert zwei Wochen er ich das verstanden habe lol.. kann auch cmake sein... wurst..
:
Bearbeitet durch User
Marco H. schrieb: > Mit eclipse gibt es dann ein Problem wenn im Nachhinein einfällt das man > daraus ein autotools Projekt machen will. Oh so schlimm ist das nicht. Schritt 1: Man macht (ohne Eclipse) händisch ein autotools- oder cmake-Projekt daraus, das sollte möglich sein da man das Projekt ja wie seine Westentasche kennt und weiß wie alles zusammenhängt und wie es gebaut werden muss Schritt 2: Man importiert es neu in Eclipse als Makefile-Projekt. Dann aktiviert man den Build-Output-Parser, teilt Eclipse mit wie der Befehl zum bauen lautet und fertig. Der Build-Output-Parser wird den Rest von Eclipse vollautomatisch so konfigurieren daß die ganze Codeassistenz wieder funktioniert, alle Pfade gefunden und alle Defines bekannt sind und alle roten Wellenlinien verschwinden.
Dazu brauche ich ja auch erst mal ein oder mehrere makefiles in jeden Unterverzeichnis. Ich könne mir noch morgen einen Blick in die Bücher, so langsam verstehe ich wie das funktioniert :)
hmm also das Thema ist mühselig.. ich schätze mal das ich wie gesagt zwei Wochen brauche im das ganze umzusetzen... Geht das nicht einfacher ? Der Syntax ist recht mühsam zu verstehen...
Marco H. schrieb: > hmm also das Thema ist mühselig.. ich schätze mal das ich wie gesagt > zwei Wochen brauche im das ganze umzusetzen... Geht das nicht einfacher > ? Der Syntax ist recht mühsam zu verstehen... Wenn Du planst in Zukunft mehr auf dieser Basis zu machen dann ist es schon ratsam sich da mal in Ruhe hinzusetzen und sich nach und nach da reinzufuchsen. Sobald Du es unter Kontrolle hast kannst Du es ja beliebig für andere neue Projekte abwandeln und wiederverwenden und dann immer weniger bis gar keine nennenswerte Zeit mehr damit verbringen. Zeitdruck ist da allerdings eher kontraproduktiv und erzeugt Streß und macht keinen Spaß. Mach die zeitkritischen Sachen erstmal weiter in altgewohnter Weise und lass das Experimentieren und Lernen von Dingen die alles auf den Kopf stellen würden außer Konkurrenz nebenher laufen.
Ich habe es hinbekommen.. Problematisch war das anlegen der Verzeichnisse. Ich habe das jetzt so gelöst das nicht jedes mal mkdir aufgerufen wird auch wenn das Verzeichnis schon vorhanden ist. Die Lösung ist trotzdem komisch...
Naja, Du kamst, fragtest und hast eine gescheite Antwort bekommen, wie man das heutzutag' macht. Einarbeitungsaufwand < 2Tage für ein erstes Projekt mit CMAKE. Wurschtl ruhig weiter mit den blöden Makefiles rum - aber das ist eher Zeitverschwendung, wenn Du mich fragst. CMAKE baut ja die Makefiles für Dich. Du brauchst ja nicht genau verstehen, was dann im Makefile genau abläuft.
soso schrieb: > Wurschtl ruhig weiter mit den blöden Makefiles rum Ich wage zu widersprechen. Bei kleinen Projekten wo keine unterschiedlichen oder plattformabhängigen Konfigurationen erforderlich sind und daher das Makefile noch auf eine Bildschirmseite passt (zum Beispiel bei µC-Projekten ist das der Regelfall) ist ein simples handgeschriebenes statisches Makefile oft die pragmatischere Wahl und mindestens ebenso akzeptabel wie das schwere Geschütz.
Marco H. schrieb: > Ich habe es hinbekommen.. Zitat:
1 | @echo " $(CC) $^ -o $(TARGET) $(LIB)"; $(CC) $^ -o $(TARGET) $(LIB) |
anstelle von
1 | $(CC) $^ -o $(TARGET) $(LIB) |
Warum gibst Du das Kommando mit @echo aus bevor Du es ausführst? Es wird doch eh auf der Konsole angezeigt wenn es normal (ohne @) aufgerufen wird. Derlei Ansinnen ist in zweierlei Hinsicht kontraproduktiv: * Du musst bei jeder Änderung auch das Echo statement mitpflegen * Wenn Du das mal vergisst steht auf der Konsole was anderes als er tatsächlich ausführt und wenn Du wirklich mal Problemen beim Buildvorgang auf der Spur bist ist es äußerst hinderlich wenn er auf der Konsole lügt er hätte gcc -x -y -z ausgeführt aber in Wirklichkeit hat er gcc -x -y aufgerufen und Du verbringst 2 Stunden damit den Fehler an anderer Stelle zu suchen. Also: geh sparsam um mit @echo um im Makefile und lass ihn einfach direkt ausgeben was er macht, und komm nicht auf die Idee das auch noch mit @ komplett unterdrücken zu wollen, das wird sich irgendwann rächen, die Ausgabe von make soll keinen Schönheitspreis gewinnen sondern vollkommen unverfälscht die Aufrufe und die Ausgaben der Kommandos anzeigen, auch wenn sie kilometerlang werden. Und auch IDEs in denen das Projekt vielleicht bearbeitet wird wollen die unverfälschten Orginalkommandos beim Build sehen damit sie sich richtig konfigurieren können.
Bernd K. schrieb: > Ich wage zu widersprechen. Naja die freie Meinungsäußerung hat aber heutzutage keinen großen Stellenwert mehr. Das weisst Du hoffentlich. Es sei Dir verziehen.
Für kleine embedded Projekte die keine bis kaum Abhängikeiten haben reicht make sicherlich. cmake ist sonst für C/C++ mittlerweile ein defakto Standard und sollte eigentlich genau da glänzen wo dutzende Abhängigkeiten zu irgendwelchen Libs und Frameworks alltäglich sind. Leider hat man aber ähnlich wie bei C++ verschlafen die gesamte Community zur richtigen "modern cmake" Anwendung zu erziehen. In der Praxis ist cmake deshalb ein absoluter cluster-fuck wo absolut jeder macht was er will und externe Projekte reinziehn in 9/10 Fällen schlichtweg nicht "einfach so" funktioniert. Erschwerend hinzu kommt dass das Netz voll ist mit miserablen und komplett veralteten Tutorials. Selbst beim offiziellen Repo sollte man die Hilfe lieber löschen als sie online zu lassen... Umso trauriger ist es, dass ich trotzdem empfehlen würde es zu lernen und zwar mit Hilfe von folgenden Videos: https://youtu.be/eC9-iRN2b04 https://youtu.be/S4QSKLXdTtA https://youtu.be/bsXLMQ6WgIk
"Warum gibst Du das Kommando mit @echo aus bevor Du es ausführst?" Das habe ich drin gelassen weil ich sehen wollte was passiert ;) und das file war als Ansatz gedacht. Mir ist schon klar das ich hier kein perfektes Ergebnis abliefere. Na dann Empfehle mal ein gutes cmake Buch? Die oben genannten Bücher sind schon ganz gut, aber man muss sie von vorne an durcharbeiten. Mal mitten drin etwas zusammen zu fummeln macht wenig Sinn. Das file habe ich schon überarbeitet und auch Compiler Flags hinzugefügt. Jetzt kann ich mit autotools versuchen ein configure script zu bauen.
:
Bearbeitet durch User
Marco H. schrieb: > "Warum gibst Du das Kommando mit @echo aus bevor Du es ausführst?" > > Das habe ich drin gelassen weil ich sehen wollte was passiert ;) Aber das siehst Du doch auch so, ganz ohne den fehlerträchtigen echo klimbim?!?!? Das echo verschleierts doch nur!
:
Bearbeitet durch User
ja klar.. habe es ja entfernt ;) Danke für den Hinweis... so mit Autotools hat es auch geklappt :) Allerdings muss ich mich noch mal schlau machen wie man die Version von Bibliotheken prüft.
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.