[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ein neues buildsystem --> autotools endlich abloesen



On 03.03.06 17:19:55, Enrico Weigelt wrote:
> * Andreas Pakulat <apaku@gmx.de> 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.



Reply to: