http://www.coocox.org lässt sich nicht (mehr) ansprechen. Liegt's an unserer restriktiven Firewall Policy in der Firma oder geht's euch von "Zuhause" aus genauso? Es gab ja mal eine CoIDE-V2Beta und ich hoffte dass daraus mal was Vernünfiges wird, aber zur Zeit schaut es nicht danach aus ....
http://downforeveryoneorjustme.com Frickelfritze schrieb: > oder geht's euch von "Zuhause" aus genauso? Geht nicht.
... wenn du merkst das du ein totes Pferd reitest, ... steig ab!
53453453454353 schrieb: > ... wenn du merkst das du ein totes Pferd reitest, ... steig ab! Hab ja nicht mal das alte lebende geritten.
Die war vor nem Monat schonmal down. Davon ab, inhaltlich ist das Projekt schon lange tot. Das Forum war nur noch Spam, null Reaktion mehr, und da die CoIDEv2 in eine vollkommen verkehrte Richtung abgebogen ist (alles nur noch online), hat die auch keiner benutzt. Zurecht, denn man sieht ja, was man davon gehabt hätte, sich auf den Online-Unsinn einzulassen. Naja, ich hab CoIDE ganz gerne genutzt, aber meine eigentlichen Builds mache ich per Batchfile, unabhängig von irgendwelchen IDEs. Deswegen werden meine Projekte auch in 10 Jahren noch durchcompilieren.
Nop schrieb: > unabhängig von irgendwelchen IDEs. Deswegen > werden meine Projekte auch in 10 Jahren noch durchcompilieren. Auch eclispe erzeugt "echte" makefiles ;-)
hp-freund schrieb: > Auch eclispe erzeugt "echte" makefiles Hab noch nie ein unechtes makefile gesehen.
Frickelfritze schrieb: > Hab noch nie ein unechtes makefile gesehen. Will sagen das auch der reine gcc ohne eclipse Bestandteile in Zukunft funktionieren wird.
hp-freund schrieb: > Auch eclispe erzeugt "echte" makefiles ;-) Jo. Und sollte man zu den überwältigenden 2% gehören, die Linux am Desktop einsetzen, dann reicht das ja auch schon aus zum Build. Super Idee.
Hier gibts noch die alte IDE zum Download. Falls sich jemand noch was "Sichern" möchte. https://web.archive.org/web/20150425052426/http://www.coocox.org/download/Tools/CoIDE-1.7.8.exe Ansonsten ist Atollic TrueStudio Lite absolut zu empfehlen! Hat keine Code-Size limitierung mehr.
Nop schrieb: > Jo. Und sollte man zu den überwältigenden 2% gehören, die Linux am > Desktop einsetzen, dann reicht das ja auch schon aus zum Build. Super > Idee. Is ja nich so, dass es gcc und make.exe auch für Windows gäbe...
:
Bearbeitet durch User
Mw E. schrieb: > Is ja nich so, dass es gcc und make.exe auch für Windows gäbe... Klar, und notfalls kann man ja auch "einfach" Cygwin installieren. Nichts gegen Cygwin, das ist super, aber barocke Build-Chains sind ein sehr eleganter Weg, wie man unwartbare Projekte erzeugen kann. Der geniale Trick daran ist nämlich, daß bei Codereviews meist nur auf den Code geachtet wird, während man das absehbare Chaos mit der Methode der Buildchain unter dem Radar der Reviewer hindurchschmuggeln kann. Natürlich ist make da nur ein ganz kleiner Baustein, der aber wenigstens das Prinzip verdeutlicht. Profis generieren aber auch noch Code mit irgendwelchen Scripten, die dann noch eine spezielle Version irgendeiner anderen Sprachumgebung verlangen. Gut umgesetzt ist das z.B. bei libopencm3, wo zum Lib-Build auf dem Host allen Ernstes Python 2.7 gebraucht wird. Den Compiler und Linker braucht man funktional gesehen, keine Frage. Aber alles andere ist IMO unnötiger Ballast, der in die "dependency hell" führt - das Linux-Äquivalent zur "DLL hell".
Nop schrieb: > Aber alles andere... Du sprichst mir aus dem Herzen. Aber sowas hier in diesem Forum öffentlich zu schreiben, ruft gewöhnlich eine Flame-Welle hervor. Denk mal an die Legion von Anfragen wie "Ich möchte mich mit µC beschäftigen, welche IDE würdet ihr mir empfehlen?" W.S.
W.S. schrieb: > Du sprichst mir aus dem Herzen. Jepp, Du bist ja auch einer der wenigen, die ein simples Shellscript/Batchfile irgendwelchen kryptischen Makefiles vorzieht, die ohnehin meist unverstanden per copy/paste realisiert werden, und wo die Leute dann dicke Backen machen, wenn es nicht geht wie gedacht. Und wo auch die make-Cracks hier mehrere Iterationen brauchen, bis sie mal was Funktionierendes vorstellen - weil's ja so einfach ist. Ja nee, is klar. Bei hunderten von C-Files verstehe ich, daß man nicht immer alles neu übersetzen will, und da ergibt make auch Sinn. Aber für embedded ist das angesichts heutiger PC-Geschwindigkeiten beim Build einfach unnütz. > Aber sowas hier in diesem Forum öffentlich zu schreiben, ruft gewöhnlich > eine Flame-Welle hervor. Was ist eigentlich aus KISS/YAGNI geworden? ;-) > Denk mal an die Legion von Anfragen wie "Ich > möchte mich mit µC beschäftigen, welche IDE würdet ihr mir empfehlen?" Das gibt es noch in viel krasser. Ich kann da nicht ins Detail gehen, aber ich habe es beruflich tatsächlich erlebt: eine embedded-IDE, die aus den Projekt-Einstellungen mit einem Zoo aus verschachtelten Klickibunt-Optionen das Startupfile generiert hat. Und zwar bei jedem Build erneut, so daß man im generierten Code nichts nach Datenblatt ändern konnte. Das war vielleicht ein Horror, wenn man irgendwas gesucht hat. Und besonders, wenn Kollegen die Sourcen eingecheckt haben, aber die Projektsettings nicht. Zumal die dann eh wieder auch noch von lokalen Pfaden auf dem jeweiligen Rechner abhingen - da kam Freude auf. Statt daß man einfach mal ganz normal mit Startup-Assembler die Grundeinstellungen macht und gut, aber nee, das wäre ja zu einfach gewesen.
Nop schrieb: > aber barocke Build-Chains sind ein sehr eleganter Weg, wie man > unwartbare Projekte erzeugen kann. Prinzipiell richtig, aber zum Glück ist weder an make noch an Python irgendwas barockes, beides sind gut etablierte Standardwerkzeuge mit breiter Nutzerbasis die auch für Windows problemlos verfügbar sind und die Wahrscheinlichkeit daß es auf einem Entwickler-PC ohnehin bereits installiert ist ist hoch. Die meisten C und C++ Projekte setzen an zentraler Stelle auf make, das kann man also guten Gewissens auf jedem Rechner auf dem mit gcc gearbeitet werden soll voraussetzen.
Bernd K. schrieb: > Prinzipiell richtig, aber zum Glück ist weder an make noch an Python > irgendwas barockes Doch. Versuch mal, in zehn Jahren ein Python mit der richtigen Version von damals zu installieren. Achso, ich vergaß, in zehn Jahren ist die Frickelsoftware von heute ja sowieso schon längst weggeworfen. Die Situation, daß man ein Projekt von vor zehn Jahren tatsächlich nochmal anfassen muß, hatte ich schon. Und das wird dann drollig, weil das Zeug von damals auf einem heutigen Windows nicht mehr unbedingt läuft, und bei Linux ist das auch nicht anders. Abgesehen davon ist scriptgenerierter Code an sich schon schlecht, weil es zu unwartbaren Projekten führt. Man kann dann nämlich den Code nicht mehr direkt warten. Das ist artverwandt zu Spaghetticode, nur in der anderen Richtung: Lasagnecode. Zuviele Schichten und Indirektionen. > Die meisten C und C++ Projekte setzen an > zentraler Stelle auf make, das kann man also guten Gewissens auf jedem > Rechner auf dem mit gcc gearbeitet werden soll voraussetzen. Nope. Wenn man sich ARM-GCC auf Windows holt, ist da erstmal kein Make dabei. Und auch kein Python und weiß der Geier. Je mehr man "guten Gewissens" voraussetzt, desto mehr geht daran am Ende schief. Was kann eigentlich daran so grundverkehrt sein, daß man schlicht und ergreifend KEINE Abhängigkeiten voraussetzt?! Ist es wirklich so schlimm, wenn ein nachfolgender Entwickler nur auf eine Batchdatei/Shellscript klicken muß und gut? Scheint wohl so: "Ich mußte mir den ganzen Kram auch erstmal aufsetzen, und durch diese Reifen muß der andere dann auch springen, haha!".
Nop schrieb: > Nope. Wenn man sich ARM-GCC auf Windows holt, ist da erstmal kein Make > dabei. Und auch kein Python und weiß der Geier. Je mehr man "guten > Gewissens" voraussetzt, desto mehr geht daran am Ende schief. make ist das De-Facto Buildsystem für C. Dessen Allgegenwart ist für den C-Programmierer so selbstverständlich wie es für den Elektriker der Phasenprüfer in der Kitteltasche ist. Wenn Du ihm den wegnimmst hat er 30min später nen neuen drin stecken. Das kann man voraussetzen. Und Python kommt auf Platz 2.
Man merkt wie nop keine Ahnung hat... Mit Argumenten steuer ich jetzt mal nicht dagegen, das würde nichts bringen. Zudem erzeugen viele IDEs intern auch "nur" ein Makefile.
Mw E. schrieb: > Man merkt wie nop keine Ahnung hat... <irony> Wieso? Ich finde seine Idee mit den Batchfiles gut. Man kann Tage,Wochen, Monate darauf abrechnen ein Batchfile zu portieren oder irgendwann mal eine spezielle Option zu ändern ohne dass irgend lemand etwas dagegen sagen kann. Denn dann müsste er sich das Elendf ja selber ansehen. Toppen kann man das vielleicht noch durch Powersh... Da kommt noch die .net Version XXX mit ins Spiel. Und irgendwann wirds auch funktionieren. Naja, vielleicht. </irony> Der einzige Anwendungsfall einer Batchdatei als Make Replacement wäre, wenn das Programm aus nur einer Datei besteht und man die Flags nicht verbummeln will. Aber selbst da schaut doch jeder erst nach einem Makefile, dann nach einem README.txt und erst zum Schluss nach einem Batchfile. Insbesondere unter Linux, wo es auch noch diverse Shells gibt und ein Batchfile nicht auf .bat enden muss. @nop: Wenn Du keine Dependencies magst dann schau Dir mal GNAT an. Da wird die Konfiguration komplett (im Klartext) im Projektfile abgelegt. /regards
Also wer "Tage" braucht, um aus einem Batchfile ein Shellscript zu machen, das vernünftig unter Linux läuft, der sollte einfach mal auf Dieter Nuhr hören. Oder alternativ lesen lernen, denn ich schrieb ausdrücklich, daß sich bei großen Projekten mit hunderten Files make sehr wohl lohnt.
Nop schrieb: > Scheint wohl so: "Ich mußte mir den ganzen Kram auch erstmal aufsetzen, > und durch diese Reifen muß der andere dann auch springen, haha!". Nein, das glaube ich eher nicht. Sowas würde ein gewisses Maß an Denken voraussetzen. Nun ja, bösartiges Denken, aber eben Denken immerhin. Hier haben wir es jedoch mit dressierten Leuten zu tun. Denen ist make oder Python eben mal eingetrichtert worden und ab da können sie nicht mehr anders. Das Bedenkliche dabei ist, daß eben diese Leute, die zu doof sind, um mal aus ihrer Furche zu gucken, sich selbst für die Allergrößten halten - mit der Begründung, daß sie vor sich in selbiger Furche ja den Allerwertesten eines Anderen sehen... also sagen sie sich "Aha, noch einer, also jaja, das MUSS eben so sein, was Anderes ist gar nicht denkbar." Natürlich ist es weder schlimm noch schwierig, mit dem modernen Faustkeil auf ein ccc.bat zu hauen (oder im TC einmal auf die Entertaste). Aber Leute, die auf "make" gedrillt wurden, kommen von sich aus nicht drauf, über sowas jemals nachzudenken. Stattdessen werden sowohl Linkerscripte als auch Makefiles kopiert und editiert, immer nach dem Motto "das hatte beim letzten Projekt gut funktioniert". W.S.
W.S. schrieb: > Das Bedenkliche dabei ist, daß eben diese Leute, die zu doof sind Das Kompliment gebe ich dir gerne zurück. Ich glaube ja, daß du und "Nop" einfach zu dämlich sind, make und Makefiles zu verstehen. Und das an sich wäre ja nicht schlimm. Eine Menge Menschen (mich eingeschlossen) sind zu dämlich für einige Dinge. Ich kann z.B. keine gerade Wand mauern und beim Polka tanzen komme ich immer aus dem Rhythmus. Der Unterschied zwischen uns ist, daß ich mich nicht hinstelle und sage "Mauern sind sowieso doof; man kann ja auch in einem Zelt wohnen". Äsop [1] läßt Grüße ausrichten! Und versteh mich recht: make ist ganz sicher nicht perfekt. Deswegen gibt es ja die ganzen Alternativen wie ANT, cook, smake und wie sie alle heißen. Aber ein Makefile ist ca. 1000-mal besser als ein Batchfile. Und zwar allein schon deswegen, weil es portabel ist. [1] https://de.wikipedia.org/wiki/Der_Fuchs_und_die_Trauben
W.S. schrieb: > Aber Leute, die auf "make" gedrillt wurden, kommen von sich aus nicht > drauf, über sowas jemals nachzudenken. Ich habe ein Projekt mit ca. 120 C-Dateien und fast ebensoviel Header-Dateien. Wenn ich nun eine Header-Datei ändere, werden mit make nur die relevanten C-Dateien, welche diese Datei per #include benutzen, neu übersetzt und nicht sämtliche 120 C-Sources. Nenne mir ein alternatives Tool, mit dem ich das Projekt ähnlich effizient übersetzt bekomme, ohne die 120 Dateien durchzunudeln und damit mindestens 10 Minuten meines Lebens zu verschwenden.
Bezüglich des Threadthemas: Unter https://coocox.org/ (https!) ist die Website erreichbar. Insbesondere das Forum macht aber einen etwas "vernachlässigten" Eindruck...
Hallo, ich finde das Thema "make" sehr interessant. Kann mir jemand sagen, wie schwer es für einen Anfänger ist sich da einzuarbeiten? Mein Hintergrund: - Ich Habe stm32-CortexM3 mit Coocox bisher programmiert und komme damit auch gut zurecht. Prinzipiell würde ich gerne ein etablierteres Programm wie zb. Keil verwenden. Leider ist das codesize beschränkt. Ist da Make eine gute Alternative? - Was wird eigentlich in der Industrie verwendet? Ist da eher Make oder Keil bevorzugt?
Frank M. schrieb: > Ich habe ein Projekt mit ca. 120 C-Dateien und fast ebensoviel > Header-Dateien. Wenn ich nun eine Header-Datei ändere, werden mit make > nur die relevanten C-Dateien, welche diese Datei per #include benutzen, > neu übersetzt und nicht sämtliche 120 C-Sources. Deswegen schrieb ich am 01.11.2016 23:30: "Bei hunderten von C-Files verstehe ich, daß man nicht immer alles neu übersetzen will, und da ergibt make auch Sinn." Aber das hat offenbar auch der Axel sehr gekonnt überlesen.
Flipp schrieb: > Prinzipiell würde ich gerne ein etablierteres Programm > wie zb. Keil verwenden. Leider ist das codesize beschränkt. Ist da Make > eine gute Alternative? lol Gut getrollt. (:
Nop schrieb: > Flipp schrieb: >> Prinzipiell würde ich gerne ein etablierteres Programm >> wie zb. Keil verwenden. Leider ist das codesize beschränkt. Ist da Make >> eine gute Alternative? > > lol Gut getrollt. (: Das war wirklich eine ernstgemeinte Frage ^^
Flipp schrieb: > - Was wird eigentlich in der Industrie verwendet? Ist da eher Make oder > Keil bevorzugt? da gibt es keinen Standard. Selbst innerhalb einer Firma gibt es genau wie hier die einen die eine IDE bevorzugen und die anderen die lieber mit make/batch arbeiten. Einfach mal nach 'make tutorial' googeln, da wirst du schon was finden. Das Grundprinzip ist einfach: es gibt ein Ziel (target) und wovon das abhängig ist. Und zu den Abhängigkeiten gibt es Regeln wie die erstellt werden. Der erste Treffer bei Google sieht doch schon gut aus, sogar in Deutsch: http://www.ijon.de/comp/tutorials/makefile.html
hp-freund schrieb: > Auch eclispe erzeugt "echte" makefiles ;-) Ja, mit absoluten Pfaden drin. Dabei wäre es so einfach, ich sag nur BASEDIR = $(realpath ..) Dann alle Pfade relativ zu $BASEDIR angeben. Dieses Makefile funktioniert dann ohne Änderungen unter Linux und Windows, egal wo man es hinlegt bzw. die Sourcen entpackt. Klar, man muss als Toolchain https://launchpad.net/gcc-arm-embedded/+download noch installieren und dazu ein make.exe (http://gnuwin32.sourceforge.net/packages/make.htm). Dazu Editor nach Wahl. O.k., beim Debuggen kann eine IDE Sinn machen.
Flipp schrieb: > ich finde das Thema "make" sehr interessant. Kann mir jemand sagen, wie > schwer es für einen Anfänger ist sich da einzuarbeiten? Einfache Dinge sind einfach, komplizierte Dinge manchmal kompliziert. Man merkt make die Herkunft aus dem Unix-Bereich an, zusammen mit typischen Linux-Tools fühlt sich make am wohlsten. Werkzeuge um automatisch Makefiles zu erzeugen, haben sich als Irrweg herausgestellt. Angefangen von imake (Benutzung des C-Preprozessor um Makefiles zu generieren) bis zu autoconf (Benutzung des M4 Macroprozessors um Makefiles zu generieren), arten alle diese Werkzeuge in eine Materialschlacht aus. > - Ich Habe stm32-CortexM3 mit Coocox bisher programmiert und komme damit > auch gut zurecht. Prinzipiell würde ich gerne ein etablierteres Programm > wie zb. Keil verwenden. Leider ist das codesize beschränkt. Ist da Make > eine gute Alternative? make beseitigt keine Codegrößenbeschränkungen des Compiler.
Jack schrieb: > Werkzeuge um automatisch Makefiles zu erzeugen, haben sich als Irrweg > herausgestellt. Angefangen von imake (Benutzung des C-Preprozessor um > Makefiles zu generieren) bis zu autoconf (Benutzung des M4 > Macroprozessors um Makefiles zu generieren), arten alle diese Werkzeuge > in eine Materialschlacht aus. Kannst du so nicht sagen. imake kommt aus der X11-Ecke und wird dort vermutlich noch immer benutzt. Ohne autoconf/automake müsste man (wie vor 25 Jahren) sämtliche Systemabhängigkeiten in config.h mit der Hand pflegen. Heute heißt es für viele Dinge doch nur: "./configure && make all install clean". Als eierlegende Wollmilchsau würde ich es aber auch nicht sehen.
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.