=> Das kann auf Dauer nicht richtig sein! <=

Mittlerweile habe ich in meiner WinXP-Installation

- Python 2.4 und 2.5
- ActivePerl
- JDK 1.6
- VC 6, VC Expresss 05, mingw, openwatcom und bcc55
- MASM und NASM
- Vier RDBMS (MySQL, Postgres, SQLite und MSSQL) jeweils mit ihren Kommandozeilentools
- Rational Rose, DBDDesigner 4, Argo UML
- CVS und SVN

von 'zig Fremdbibliotheken ganz zu schweigen..

Ich vermute dass es auf Euren privaten Entwicklungsrechnern nicht viel anders aussieht.

Die Compiler/Interpreter brauchen natürlich jeweils Umgebungen.
Die SQL Tools brauchen jeweils eigene Verbindungsparameter.
Die UML/ER-Werkzeuge brauchen oft Verzeichnisse zur Codegenerierung.

Ferner gibt es jeweils eine Bibliothek für Python und C++ und Frameworks für jeweils C++, Python und Perl die sinnvollerweise für alle Projekte verfügbar sein sollten.

=> Da muss sich doch was verskripten lassen! <=

Jetzt überleg ich mir wie ich das

- möglichst klein
- portabel (soll auch unter Linux funzen)
- und möglichst offen

entwerfen soll:

- XML Konfigurationsdateien scheinen mir sinnvoll
- Projektspezifische Configs per "Cloning" von Default-Parametern plus Anpassung oder nur Anpassung (was gesetzt ist gilt deklaratorisch; sonst Default)?
- Es soll in einer Skriptsprache (Perl oder Python) implementiert werden; gäbe eine Hemmschwelle unter Windows ActivePerl zu installieren wenn man Perl sonst nicht einsetzt?

Die letzte Frage stellt sich v.a. da, wenn grundlegende Funktionalität da ist, ich das zum OpenSource machen möchte.

Dann stellt sich mir noch die bange Frage ob und ggf. wie man sowas zu einem Meta-Buildsystem machen könnte/sollte:
Es gibt ja Ant, die autotools, scons etc.; ist es sinnvoll Schnittstellen vorzusehen oder konkurriert solch ein Vorhaben eher mit vorhandenen Lösungen?

Erstmal geht's mir jetzt um einen Quick-n-Dirty Hack da ich sowas jetzt akut brauche, aber einige Designaspekte will ich trotzdem zumindest im Hinterkopf haben.

Habt ihr Ideen/Anregungen dazu?
Oder wird auch solch eine heterogene Infrastruktur von vorhandenen Lösungen schon hinreichend gut abgedeckt und ich erfinde grade das Rad neu?

Danke für's Lesen und Grüsse

*this

aber für was? Eines für alle Sprachen?

Das wäre wohl etwas hoch gegriffen; aber für die im OP genannten Sprachen
lassen sich Gruppen von für Build-Systeme relevanten Features finden

Zentral dürften die Begriffe "Pfad" und "Modul" sein;

- C/C++/Python/Perl/Java arbeiten alle mit Pfaden in denen irgendwelche Module zu finden sind, egal ob das nun C++ Includes, Libs, Java-jars oder Python Packages sind.

- Alle Werkzeuge brauchen auch Ausgabepfade.

Das sind schon mal zwei Abstraktionen die bei einer Modellierung eine Rolle spielen werden.

---

Meckert mich nicht an weil die Anforderungen noch wenig konkret sind; das ist halt so wenn man anfängt über ein Problem nachzudenken.
Es geht mir auch darum zunächst mal Anforderungen an ein Build-System für derart heterogene Umgebungen zu definieren.

Manche posten hier weil sie ein konkretes Problem in irgendeiner Sprache haben und ich suche halt Brainstorming mit kompetenten Entwicklern.

Ist das schlimm?

Grüsse

*this

Meckert mich nicht an weil die Anforderungen noch wenig konkret sind; das ist halt so wenn man anfängt über ein Problem nachzudenken.
Es geht mir auch darum zunächst mal Anforderungen an ein Build-System für derart heterogene Umgebungen zu definieren.

Manche posten hier weil sie ein konkretes Problem in irgendeiner Sprache haben und ich suche halt Brainstorming mit kompetenten Entwicklern.

Ist das schlimm?

Es meckert dich niemand an, es ist nur nicht wirklich ersichtlich was du überhaupt vorhast, bzw. welches Problem du lösen willst.

Willst du ein neues Buildsystem auf die Beine stellen (damit du dann an dessen Files "rumhacken" kannst)? Einen Makefile-Makroprozessor? Sprach- und/oder toolunabhängige Projekt-Templates?

Davon unabhängig mein Beitrag: statt mittels Python oder Perl ein bisher schwammig spezifiziertes Ant zu basteln, würde ich wohl eher zu einer Art Framework + Tool(s) für ein schlankes, minimales Scheme tendieren.

es ist nur nicht wirklich ersichtlich was du überhaupt vorhast, bzw. welches Problem du lösen willst.

Willst du ein neues Buildsystem auf die Beine stellen (damit du dann an dessen Files "rumhacken" kannst)?

Soll ich Dir jetzt erklären was ein Build-System ist?
Willste mich heute veralbern?

finix schrieb:

Einen Makefile-Makroprozessor? Sprach- und/oder toolunabhängige Projekt-Templates?

Lies meine Beiträge doch einfach nochmal. Was steht da drin? Richtig - ich such grade nach Ideen.

finix schrieb:

Davon unabhängig mein Beitrag: statt mittels Python oder Perl ein bisher schwammig spezifiziertes Ant

Das könntest Du sicherlich auch wertfrei ausdrücken. Oder etwa nicht?

Welcher Anwender kommt in der Praxis mit einem vollständigen Pflichtenheft wedelnd zu Euch das dann auch noch realisierbar ist?

Habe ich zumindest noch nie erlebt. Ist auch eigentlich nur im Sinne des Wasserfallmodells "wünschenswert". Seit Booch u.a. betrachtet man Softwareentwicklung als einen iterativen Prozess.

finix schrieb:

zu basteln, würde ich wohl eher zu einer Art Framework + Tool(s) für ein schlankes, minimales Scheme tendieren.

Scheme? Der Lisp-Dialekt? Welche Vorteile bringt das ggü. Perl und Python?

Grüsse

*this

finix schrieb:

es ist nur nicht wirklich ersichtlich was du überhaupt vorhast, bzw. welches Problem du lösen willst.

Willst du ein neues Buildsystem auf die Beine stellen (damit du dann an dessen Files "rumhacken" kannst)?

Soll ich Dir jetzt erklären was ein Build-System ist?
Willste mich heute veralbern?

finix schrieb:

Einen Makefile-Makroprozessor? Sprach- und/oder toolunabhängige Projekt-Templates?

Lies meine Beiträge doch einfach nochmal. Was steht da drin? Richtig - ich such grade nach Ideen.

Mir ist durchaus klar was ein Build-System ist. Ich wusste nur nicht dass du schlicht ein weiteres in die Welt setzen willst.

Was soll dein Build-System anders, besser machen? Was hat dich am Makefile-hacken gestört?

Gast++ schrieb:

finix schrieb:

Davon unabhängig mein Beitrag: statt mittels Python oder Perl ein bisher schwammig spezifiziertes Ant

Das könntest Du sicherlich auch wertfrei ausdrücken. Oder etwa nicht?

Ich hatte zunächst überlegt das nochmal zu editieren, weil ich mir schon dachte dass du so reagierst

Aber das ist wertfrei ausgedrückt.

Gast++ schrieb:

finix schrieb:

zu basteln, würde ich wohl eher zu einer Art Framework + Tool(s) für ein schlankes, minimales Scheme tendieren.

Scheme? Der Lisp-Dialekt? Welche Vorteile bringt das ggü. Perl und Python?

Dass du dich z.B. nicht mit XML herumschlagen musst

Mir ist durchaus klar was ein Build-System ist.

Das dachte ich mir irgendwie schon...

finix schrieb:

Was soll dein Build-System anders, besser machen? Was hat dich am Makefile-hacken gestört?

Bei jedem neuen Makefile das man schreibt weiss man mehr über die Werkzeuge mit denen man arbeitet. Dies Wissen sollte deshalb an einer zentralen Stelle in den Entwicklungprozess einfliessen.

Ausserdem finde ich's einfach müssig für z.B. ein kleines Testprogramm die gleiche Konfigurationsarbeit zu leisten wie für den Testling. Ferner ist dies manuelle Hacken von Makefiles höchst fehlerträchtig; mein "Lieblingsfehler" ist zur Zeit Applikationen mit Multithreading gegen singlethreaded RT zu linken...

finix schrieb:

Dass du dich z.B. nicht mit XML herumschlagen musst

Damit sich solch eine Lösung möglichst einfach in vorhandene Umgebungen (z.B. IDEs) einfügt halte ich XML-Einsatz für praktisch unumgänglich. Das stört mich auch nicht, da ich mich mit XML recht gut auskenne.

Die Ausgabe des Systems, also etwa die Generierung von make/nmake - Makefiles will ich mit XSLT bewerkstelligen. Anyway - Scheme wird's nicht werden da ich das nicht kenne und Lisp einfach nicht mag. Perl und Python sind sicherlich mächtig genug.

- Für Perl gibt's eine riesige Bibliothek von Modulen die später an ein solches Buildsystem angeflanscht werden könnten; dafür ist die OO lausig. Und es könnte später ein Hindernis in der Verbreitung sein wenn unter Win32 ActivePerl installiert werden muss - das ist ein ziemlich großer Klotz.

- Python ist von Haus aus recht kompakt, aber es ist fraglich ob Entwickler von Tools die (Softwareentwicklungs-)prozessorientiert sind nicht eher Perl bevorzugen. Perl bietet diese geniale Paketverwaltung via CPAN und sowas ist natürlich super um definierte Entwicklungsumgebungen herzustellen resp zu reproduzieren.

Grüsse

*this

P.S.:

finix schrieb:

Aber das ist wertfrei ausgedrückt.

Na ja...

Bei jedem neuen Makefile das man schreibt weiss man mehr über die Werkzeuge mit denen man arbeitet. Dies Wissen sollte deshalb an einer zentralen Stelle in den Entwicklungprozess einfliessen.

Ja, natürlich, aber da bleibt - immer noch - die Frage welches Wissen sollte mit einfließen, was ist automatisierbar, unterstützbar, was wäre sinnvoll; was soll das Tool können, und, vor allem, was soll es nicht können? Was ist der Ausgangspunkt, wo liegt der Fokus, die Vision hinter deinem Projekt?

Gast++ schrieb:

Ausserdem finde ich's einfach müssig für z.B. ein kleines Testprogramm die gleiche Konfigurationsarbeit zu leisten wie für den Testling.
Ferner ist dies manuelle Hacken von Makefiles höchst fehlerträchtig; mein "Lieblingsfehler" ist zur Zeit Applikationen mit Multithreading gegen singlethreaded RT zu linken...

Das ist doch mal was konkretes. Welche Lösung schwebt dir hier vor - semi-intelligentes Copy&Paste oder ein mit Metainformationen gespicktes Lib-/Projektrepository samt validierender Template-Engine?

Gast++ schrieb:

Damit sich solch eine Lösung möglichst einfach in vorhandene Umgebungen (z.B. IDEs) einfügt halte ich XML-Einsatz für praktisch unumgänglich. Das stört mich auch nicht, da ich mich mit XML recht gut auskenne.

Kannst du das nochmal erläutern? Wieso ist XML unumgänglich?

Gast++ schrieb:

Die Ausgabe des Systems, also etwa die Generierung von make/nmake - Makefiles will ich mit XSLT bewerkstelligen.

Ja, so was habe ich mir schon gedacht, deswegen habe ich auch Scheme vorgeschlagen.
(Google: Greenspun's tenth rule)

Gast++ schrieb:

Anyway - Scheme wird's nicht werden da ich das nicht kenne und Lisp einfach nicht mag. Perl und Python sind sicherlich mächtig genug.

Unabhängig hiervon, solltest du's dir einfach mal anschauen: Structure and Interpretation of Computer Programs (Video Lectures), Implementation+IDE: DrScheme.

Gast++ schrieb:

- Für Perl gibt's eine riesige Bibliothek von Modulen die später an ein solches Buildsystem angeflanscht werden könnten; dafür ist die OO lausig. Und es könnte später ein Hindernis in der Verbreitung sein wenn unter Win32 ActivePerl installiert werden muss - das ist ein ziemlich großer Klotz.

Hehe, ein "ziemlich großer Klotz"? Active Perl für ein Build-System ist wie die aktuelle JRE für ein paar Desktop-Post-Its
Die riesige Bibliothek ist natürlich ein Argument - nur, siehe auch oben, wozu solltest du die brauchen?

Gast++ schrieb:

- Python ist von Haus aus recht kompakt, aber es ist fraglich ob Entwickler von Tools die (Softwareentwicklungs-)prozessorientiert sind nicht eher Perl bevorzugen. Perl bietet diese geniale Paketverwaltung via CPAN und sowas ist natürlich super um definierte Entwicklungsumgebungen herzustellen resp zu reproduzieren.

Hmm. Entwickler sollten die Tools verwenden die am sinnvollsten sind, meinst du nicht?

(Hätte ich persönlich die Wahl zwischen White Noise und Significant Whitespace... ich würde wohl Python wählen, auch ohne die Größe.)

Gast++ schrieb:

P.S.:

finix schrieb:

Aber das ist wertfrei ausgedrückt.

Na ja...

Lies meine Signatur
(Zumindest war's wertfei gemeint )