|
Anzeige
|
Build script make.sh nennen?
Gast
#7553188
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? ;-)
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.
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,
Dann benenn' es halt bei dir um.
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
Gast
#7553323
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.
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.
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.
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.
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.
Gast
#7553469
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.
Die ganze Cloud-Diskussion hat mit der Originalfrage rein gar nichts zu tun. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
