(rüber auf aqbanking-devel) Am Samstag, 17. November 2007 12:02 schrieb Martin Preuss: > > (Nebenbei: Die 4 commits hatte ich in einem lokalen git-repo vorbereitet > > und deswegen auf einem Rutsch hochgeladen. Wenn sie wieder revertet > > werden sollen, geht das vom lokalen git-Repo auch am schnellsten; ) > > Ich weiss nicht, ob ich alle relevanten Aenderungen gefunden habe...
Hast du, ja. Außer die Dokumentation in src/base/pathmanager.h für AddRelPath, die schon reichlich veraltet war und wo ich deshalb das reingeschrieben habe, was ich *vermutet* habe, was dort passieren soll. Wenn wir das hier fertig diskutiert haben, wird das wohl nochmal angepasst werden müssen. > > > schaue mal in README.W32 nach, ich benutze unter Windows nicht die > > > Installationspfade wie unter Linux... > > > > äh... ich benutze unter windows ganz normal "make install". Das benutzt > > auch das gleiche Pfad-Layout wie unter Linux. Daher diese Änderung. > > [...] > Das verwende ich fuer Windows gerade nicht: Unter Windows ist das > Linux-Layout nicht ueblich, daher verwende ich hier ein vereinfachtes > Layout. Es gibt beispielsweise keinen Grund, die vollstaendige > Verschachtelungstiefe fuer die Plugins (incl. SO-Version) bei Windows zu > verwenden, wenn AqBanking Teil des Paketes einer Anwendung ist (das ist das > Hauptziel unter Windows, andernfalls bekommt man hier auch Schwierigkeiten, > weil die DLLs nicht gefunden werden etc). > Auch ist es unter Windows unnoetig, die Locale-Dateien in /share/locale" > abzulegen, denn AqBanking und Gwen nicht auf das Linux-Layout angewiesen. Also die Tatsachen sind erstmal so: Wir haben eine bisherige Platform (Linux) und deren install-Layout. Wenn du jetzt eine neue Platform hinzunimmst (Windows), steht es dir natürlich frei, dir dafür auch ein neues install-layout zu überlegen. Ich seh die Aufgabenstellung nun genau anders herum: Wird der Aufwand genau dann minimiert, wenn das existierende install-Layout auch unverändert auf der neuen Platform benutzt wird, oder würde das zusätzlichen Aufwand bedeuten? Und da seh ich halt ganz klar, dass das Linux-Layout sehr wohl auch auf Windows benutzt werden kann, ohne dass irgendwelche Einschränkungen daraus entstehen. Und gleichzeitig hätte man den Vorteil, dass der bisherige Linux-install-Code eben für Windows unverändert genutzt werden kann. > Das hat derzeit noch den Effekt, dass man unter Windows nicht einfach "make > install" verwenden kann, letztlich macht das aber auch gar keinen Sinn, > weil die Libs unter Windows (zumindest mit meinem Target mp-w32) ja > relocatibel sind. Sind sie ja auch bei "make install". Der Target hat sehr wohl einen Sinn, weil ausschließlich über diesen Target die library-Header installiert werden und die privaten Headers nicht. Andernfalls müsstest du immer "make install" *plus* zusätzlichem herumkopieren mindestens der Headers machen. Also den install-Target brauchst du auf jedem Fall. Es geht hier nur noch um die Frage, ob du *zusätzlich* die install-Directories veränderst oder herumkopierst. > Ich werde dazu vermutlich mal ein neues Target > einrichten, was die Dateien entsprechend dem vereinfachten Layout ablegen > kann. Aber wozu der Zusatzaufwand hier? Meine Intention hinter "make install" ist doch gerade, dass wir *keinen* zusätzlichen Target bei win32 brauchen, sondern alles so läuft wie bei Linux. Das Argument hier ist dann, dass diese Vorgehensweise bei gwenhywfar2 im gnucash-binary wie gesagt seit einem guten Jahr problemlos funktioniert. > > > Schaue Dir bitte auch mal mein WIN32-Target im Makefile an, da siehst > > > Du, wie das alles gemeint ist. > > > > äh... der win32-Target im top-level Makefile.am? Der ist doch uralt. Ich > > bin davon ausgegangen, dass der schon ewig nicht mehr benutzt wird. Vor > > allem, da wie gesagt "make;make install" abgesehen von dieser neueren > > Sache korrekt funktioniert. > > [...] > Nein, ich meine natuerlich mp-w32, sorry. In Makefile.cvs. Um zukünftige Missverständnisse zu vermeiden, hab ich das alte in Makefile.am rausgeschmissen. Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Aqbanking-devel mailing list Aqbanking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
