[DEV] lib/* entpacken, cwberlios.jnf

[mirabilos]

Hallo Leute,

neben der Zeilenendenkonversion, über die ich bald einen Extrathread
aufmachen werde, brennt mir noch folgendes Problem unter den
Nägeln, bevor ich ENDLICH ein Unix-Makefile einchecken kann:
Einige der Dateien in lib/ müssen sowieso zum .ewe-Bauen entpackt
werden; das müssen sie auch, wenn man mit gcj kompiliert und dann
mit Ewe lokal direkt die *.class testet (bevor man die .ewe dann baut),
hättet ihr was dagegen, wenn ich die direkt in ihrer ENTPACKTEN Form
einchecke und die zips bzw. das jar dann lösche, wenn es überflüssig
geworden ist? Eclipse-Nutzer müßten ggf. noch „./lib/“ in ihren Class-
path mit aufnehmen danach, sonst sollte das transparent sein (die
Batchdateien usw. passe ich selbstredend an).

cwberlios.jnf: Diese verwendet Pfadnamen wie „./bin/*“, welche bei
mir mit Lunix-Ewe und Jewel Probleme verursachen (genauer: die
*.class Dateien werden nicht gefunden), was sich durch Ändern der
Angaben von z.B. „./bin/“ auf „bin/“ beheben läßt. Da „./“ eigentlich
eh eine Nullnummer ist („.“ ist ja das aktuelle Verzeichnis), könnte
man diese doch entfernen, oder?

Soll ich das einfach mal so committen, und wenns wo nicht tut,
können wir gucken, ob wirs behoben kriegen und andernfalls
die Änderung reverten?

 

[mirabilos]

Ahso, und nochwas: man könnte Jewel auch direkt in den
Sourcetree integrieren, sodaß man nicht extra noch das
Ewe-SDK entpacken muß, nur um eine Version zu bauen.

Bezüglich Ewe: das Forken und Herausgeben einer fehler-
bereinigten Version (inklusive Debian-Rules) von Lunix-Ewe
mache ich auf jeden Fall, gebt mir nur ein bißchen Zeit.
Wenn Euch das lieber ist kann ich das auch direkt im CW-SVN
machen, sonst läuft das über meinen eigenen Server und
dessen Versionsverwaltung, wie bereits einige andere Projekte.

 

[pfeffer]

ich bin dafür, dass selbstbauen so einfach wie möglich zu machen. Am besten so: svn check out -> buildexe.sh oder buildexe.bat aufrufen -> fertig.

Wenn das ginge, wäre super. Dazu müsste dann antürlich die "anleitung für Entwickler" angepasst werden.

Schöne Grüße,
Pfeffer.

 

[Kalli]

Ich bin auch pfeffers Meinung, man sollte durch ein paar Kommandozeilenbefehle eine lauffähige Version bekommen. Ich hatte damals glaube ich die .zips eingecheckt, weil ich es so für eclipse brauchte und auch nicht tausende von Dateien ins Repository packen wollte. Beim Löschen bitte beachten, dass in einigen Zips auch der Sourcecode drin ist, z.B. für die Template-Engine und die openmap Geschichte. Die Sachen müsste man dann auch unter die Versionsverwaltung stellen.

Die Sourcen des ewe-Fork würde ich getrennt halten, das wird sich wahrscheinlich nicht jeder selbst bauen. Neben Jewel benötigt man doch auch einige andere Sachen aus dem SDK. Wenn aber ewe geforkt wird und z.B. auch Fehler in der Windows-Version gefixt werden, macht es Sinn, alles, was für den Build benötigt wird, über svn zu verwalten, damit man nach einem svn update alles notwendige auf der Platte hat.

 

[mirabilos]

Okay, den Ewe-Fork habe ich gestern angefangen, während
Dr. Pfeffer an alternativen Kartenquellen gearbeitet hat (wir
haben eine gemeinsame (IRL) Hacksession gemacht). Dieser
liegt unter http://cvs.mirbsd.de/contrib/hosted/ewe/ und ist
noch nicht fertig, das Neubauen der Klassenbibliotheken ist
nōntrivial. Zum Auschecken:

cvs -d [email protected]:/cvs co -PA ewe

Das Entpacken wäre dann natürlich transparent, und Eclipse
sollte™ man das auch beibringen können (kann ich Dr. Pfeffer
ja dann testen lassen).

Via Kommandozeile (nōninteraktiv) .ewe bauen kann ich schon,
.exe bauen sollte machbar sein, werde ich bei Gelegenheit mal
etwas Arbeit reininvestieren. Dann kann ich gerne auch einen
Server damit belasten, jede Nacht eine „daily snapshot build“
zu produzieren, ich wüßte da schon einen, der mir zur Verfügung
steht… *grins* (Developer in mehreren Projekten zu sein hat
eben auch viele Vorteile, nicht nur den Zeitnachteil)