Ich habe neulich ein Software-Projekt gesehen, das mit einem Build Script Namens make.sh (und make.bat) ausgeliefert wurde. Den Befehl "make" assoziiere ich stark mit einem Makefile, deswegen finde ich diesen Namen unpassend. Ich bin eher gewohnt, dass solche Scripte build.sh oder compile.sh heißen. Wie sind da eure Erfahrungen?
Wenn ich ein Makefile habe, wozu dann das Skript? Und wenn nicht, warum nicht? ;-)
Steve van de Grens schrieb: > Den Befehl "make" assoziiere ich stark mit einem Makefile, deswegen > finde ich diesen Namen unpassend Naja, keiner wird denken dass "make.sh" ein Makefile ist. Ich finde es völlig wurscht, make.sh ist als Name völlig in Ordnung. Es impliziert auch schön dass dort (indirekt) make aufgerufen wird. Rolf M. schrieb: > Wenn ich ein Makefile habe, wozu dann das Skript? Grade zum Crosscompilen sind gerne mal eine Menge Optionen & Umgebungsvariablen für make nötig, oder auch Aufrufe an Packagemanager wie conan.io oder vcpkg... Die würde man typischerweise in ein Build-Script verpacken.
Moin, Steve van de Grens schrieb: > Ich bin eher gewohnt, dass solche > Scripte build.sh oder compile.sh heißen. Dann benenn' es halt bei dir um. > Wie sind da eure Erfahrungen? So wie ich das sehe, scheint fast jeder Depp von Informatiker extrem drauf abzufahren, irgendein Buildsystem oder irgendwas, was Dokumentation "automatisiert" erstellen koennen soll, zum Segen der Menschheit unbedingt entwickeln zu muessen. Naja, sollnse halt...Man muss och joenne koenne. Gruss WK
Dergute W. schrieb: > So wie ich das sehe, scheint fast jeder Depp von Informatiker extrem > drauf abzufahren, irgendein Buildsystem oder irgendwas, was > Dokumentation "automatisiert" erstellen koennen soll, zum Segen der > Menschheit unbedingt entwickeln zu muessen. Manager wollen regelmäßige Arbeitsschritte möglichst weit automatisiert haben, um Fehler zu vermeiden, um schnell liefern zu können, und neues Personal schnell arbeitsfähig zu haben. Ich denke, das macht schon Sinn. IT Fachleute automatisieren ihren eigenen Job weg. Das war schon immer so. Man sieht aber auch, das die Branche sehr Kreativ darin ist, sich immer wieder neue Arbeit zu schaffen. Cloud Computing ist da ein Paradebeispiel.
Steve van de Grens schrieb: > Ich bin eher gewohnt, dass solche Scripte build.sh oder compile.sh > heißen. Heißen sie oft, ja. Aber ist auch völlig egal hier, denn make.sh kann man nur explizit als make.sh aufrufen, sodass die Sache klar ist – anders als ein make.bat, welches man auch einfach als "make" aufrufen könnte.
Niklas G. schrieb: > Rolf M. schrieb: >> Wenn ich ein Makefile habe, wozu dann das Skript? > > Grade zum Crosscompilen sind gerne mal eine Menge Optionen & > Umgebungsvariablen für make nötig, oder auch Aufrufe an Packagemanager > wie conan.io oder vcpkg... Die würde man typischerweise in ein > Build-Script verpacken. Ich nehme heute eigentlich wenn's geht immer CMake. Da kann man solche Optionen drin unterbringen und dann mit ccmake, cmake-qt oder ggf. eingebauten Funktionen der IDE schön komfortabel einstellen. Dergute W. schrieb: >> Wie sind da eure Erfahrungen? > So wie ich das sehe, scheint fast jeder Depp von Informatiker extrem > drauf abzufahren, irgendein Buildsystem oder irgendwas, was > Dokumentation "automatisiert" erstellen koennen soll, zum Segen der > Menschheit unbedingt entwickeln zu muessen. Nicht zum "Segen der Menschheit", aber es ist halt ein grundlegendes Tool, um vernünftig arbeiten zu können, genauso wie ein Versionierungstool wie z.B. git. Das gehört einfach in den Werkzeugkasten eines Software-Entwicklers mit rein.
Steve van de Grens schrieb: > Das war schon immer > so. Man sieht aber auch, das die Branche sehr Kreativ darin ist, sich > immer wieder neue Arbeit zu schaffen. Cloud Computing ist da ein > Paradebeispiel. Wie viele Projekte wurden verkompliziert durch die Verwendung von Cloud-Plattformen statt eigener selbstverwalteter Server, und wie viele wurden dadurch vereinfacht? Ich kenne nur solche der letzteren Art.
Niklas G. schrieb: > Ich kenne nur solche der letzteren Art. Ich kenne beides, gute und schlechte Fälle. Viele haben sich eine Cloud aufschwatzen lassen, obwohl dafür gar kein Bedarf bestand und die dorthin migrierte Software dafür schlecht geeignet ist. In solchen Fällen bringt die Cloud unnötige Komplexität. Jemand, der meinen Chef beriet, sagte treffend: Tun sie sich das nur dann an, wenn sie es wirklich brauchen. Die Möglichkeit, auf Knopfdruck horizontal zu skalierem ist zum Beispiel verlockend, aber wenn man sie nicht braucht, dann ist der damit verbundene Overhead eine ständige teure Last. Zudem ist es teuer, die Hoheit über die Daten zu behalten, wenn man einen der drei großen Dienstleister verwendet. Andererseits ist eigenes Personal zum Betrieb einer eigenen vernünftigen Cloud ebenfalls teuer. Zum Betrieb gehört ja auch, einen ziemlich hohen Stapel an abhängigen Programmen aktuell zu halten und sicher zu konfigurieren. Da ist ständig Bewegung drin. Wenn du es schaffst, einem Mittelständischen Unternehmen eine Migration zu einer Cloud zu verkaufen, dann hast du damit gleich mehreren Leuten einen langfristigen Job besorgt. Denn so eine Cloud hält sich nicht selbst am Laufen. Um auf den Auslöser dieser Seiten-Diskussion zurück zu kommen: Die IT versteht es ganz gut, Cloud System zu vermarkten und damit ihre Jobs zu erhalten. Als Programmierer bin ich ein direkter Profiteur dieses Wahnsinns.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Um auf den Auslöser dieser Seiten-Diskussion zurück zu kommen Die ganze Cloud-Diskussion hat mit der Originalfrage rein gar nichts zu tun.
:
Bearbeitet durch Moderator
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.