On 03.03.06 17:19:55, Enrico Weigelt wrote: > * Andreas Pakulat <[EMAIL PROTECTED]> schrieb: > > Was ist wenn sich die Anforderungen einer Applikation aendert, muss > > ich dann alle Implementationen der buildtools aendern um einen neuen > > Check zu integrieren? > > Ich werde erstmal eine ganze Reihe Anwendungen (zB. Xorg-mod) portieren. > Dann müßt ich erstmal genug Fallbeispiele haben, um die wichtigsten > Systemgegebenheiten zu berücksichtigen.
Auf allen Architekturen/Plattformen auf die sie jeweils laufen koennen? Mit allen Varianten? Gut, dann sehen wir uns in 3 Jahren wieder ;-) > Wer dann noch weitere Fälle berücksichtigt werden sollen, dann muß > das eben mit dem Gremium abgestimmt werden. Das wird ein no-go sein. IMHO muss ein Buildsystem vom Entwickler erweitert werden koennen wenn sich neuere Anforderungen ergeben. Wenn zum Beispiel eine neue Bibliothek erscheint und eine Applikation Y diese optional einbinden moechte. Oder wenn sich bestimmte Dinge in einer Abhaengigkeit aendern auf die man testen will/muss. > Als Anwender muß man eben damit rechnen, daß man immer die neueste > Version des Buildsystems installieren muß. Auf Veraltetes kann keine > Rücksicht genommen werden. Erklaer das mal den Leuten die Debian stable einsetzen wollen, aber trotzdem z.B. von Spamassassin aktuellere Versionen bauen. > > > definiert, die vom unitool als Symbole an den Compiler gegeben werden > > > (aber auch innerhalb des Buildsystems, zB. für conditionals > > > einbezogen werden können) > > > > s.o. Wie siehts mit der Erweiterbarkeit aus? > > Gibt es per Definition nicht. Wenn neue Knotentypen benötigt werden, > muß das Buildsystem weiterentwickelt werden. Als Programmierer sollte > man sich bemühen, mit dem auszukommen, was geboten wird. Der war gut. Wenn ich eine Applikation entwickle entscheide ich mich fuer eine bestimmte Menge an Abhaengigkeiten. Diese Abhaengigkeiten koennen sich aber ueber die Zeit veraendern, das heisst entweder muss ich _immer_ auf die zur Entwicklung benutzte Version der Bibliothek/anderen App dependen oder aber ich nehme ein erweiterbares Buildsystem. Wie wird das mit CVS/SVN-Versionen von Bibliotheken ohne klare Versionsnummer funktionieren? > > > Diese Variablen müssen aber wohldefiniert sein, damit sie möglichst > > > allgemeingültig und global zuverlässig sind und keine per-package- > > > checks mehr nötig sind. > > > > "wohldefiniert" bedeutet hier wohl sowas wie moeglichst > > aussagekraeftiger Name und wiederverwendbar... > > Richtig. Es werden klare Interfaces definiert (zB. BSD-sockets), die > entweder vorhanden sind oder fehlen. Ein Paket kann das nun entweder > vorraussetzen (require) oder verzweigen (conditional). Aber es kann > nicht so weitergehen, daß jeder irgentwelche Hacks produziert, > die irgentwas zu erraten versuchen und mehr schlecht als recht > funktionieren. Und wer soll die "Milliarden" moeglichen "Checks" maintainen? Ich sehe durchaus ein, dass es schwierig ist wenn Hinz und Kunz ihre eigenen Makros definieren die nur auf dem eigenen System funktionieren. Aber das hat meistens einen entscheidenden Einfluss auf die (Nicht-) Akzeptanz solcher Applikationen. > > > Ich verlange keinen gij von Dir, sondern eine jvm Deiner Wahl. > > > Es sollte auch eine embedded-jvm (zb. kvm) tun. > > > > Hast du das auch schon getestet? > > Noch nicht. Aber da ich nur die grundlegenden Funktionen verwende > (keine GUI, keine templates, etc) und überhaupt der Code recht > schmal ist, sollte das kein Problem darstellen. Ich glaube kaum das das so bleiben wird (also das mit dem schmalen Code). > > > Ich portiere Xorg-mod auf mein buildsystem. > > > > Also Xorg 7.0? Interessant. > > Ja. Das ist nicht ganz trivial. Besonders beim X-server wirds > spannend - der läßt sich so schon kaum compilieren ... :-) Ich hab X.org 6.8 bisher 1x kompilieren koennen und das war schon ein Krampf... Aber nur zu, wenn dein System mal was "kleineres" bauen kann (eine KDE-App) schau ich mir das vllt. trotzdem mal an. Andreas PS: Nimm mir meine Kommentare nicht uebel, ich nehme immer alles auseinander, hab schon mit 3 Jahren damit angefangen ;-) -- Stay the curse. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
