ASM Inline code x64

[himitsu]

Nja, vermutlich sind die Abhängigkeiten eher für sowas wie Packages gedacht, welche ja naturbedingt im selben System vorliegen.

[venice2]

Zitat von himitsu:

Nja, vermutlich sind die Abhängigkeiten eher für sowas wie Packages gedacht, welche ja naturbedingt im selben System vorliegen.

Möglich nur dann sollte man das dem Developer mitteilen so das er es gar nicht erst versucht. Traurig das ganze.
Nur wenn ich mit DLL's arbeite werden diese ja auch als Abhängigkeit addiert.

Fazit daraus..
Abhängigkeit scheint nicht gleich Abhängigkeit zu sein.
Es steht hier nicht das Abhängigkeit ausschließlich für Bibliotheken vorgesehen sind.

[himitsu]

siehe mein kleines Beispiel


Gut ist erstmal, dass die Settings der DPROJ verwendet werden, aber halt die aus der falschen Plattform.
Nur dass die Platform-Config ja hier nicht vorhanden ist und somit wird zumindes deren Vorfahre genutzt.


Aber noch schlimmer, es wird "teilweise" auch die falsche Config (Build) verwendet.
Und selbst wenn ich Erzeugen (Build), wird nur kompiliert (compile) und dann doch die falsche Config genutzt (vorher kompilierte DCU).

[venice2]

Zitat von himitsu:

siehe mein kleines Beispiel


Gut ist erstmal, dass die Settings der DPROJ verwendet werden, aber halt die aus der falschen Plattform.
Nur dass die Platform-Config ja hier nicht vorhanden ist und somit wird zumindes deren Vorfahre genutzt.


Aber noch schlimmer, es wird "teilweise" auch die falsche Config (Build) verwendet.
Und selbst wenn ich Erzeugen (Build), wird nur kompiliert (compile) und dann doch die falsche Config genutzt (vorher kompilierte DCU).

Ja aber das ist doch ein Problem von Delphi nicht eins vom Entwickler.

[jaenicke]

Das ist schon korrekt so. Und normalerweise ist es auch das, was man möchte. In deinem Fall leider nicht.

Ich habe eine Projektgruppe mit einer Exe und diversen DLLs. Diese kompiliere ich mal für 64-Bit und mal für 32-Bit. Deshalb sind die DLLs als Abhängigkeiten der Exe definiert. Auf die Weise kann ich einfach die Zielplattform der Exe auf 32-Bit oder 64-Bit stellen und die DLLs werden dazu passend erstellt.
Ansonsten müsste ich ja die Zielplattform jeder einzelnen DLL korrekt einstellen...

Der Anwendungsfall, dass man eine Abhängigkeit mit einer anderen Bittigkeit hat, dürfte recht selten sein...

Trotzdem wäre es eine Möglichkeit, dass erkannt wird, wenn ein Projekt gar nicht für 64-Bit konfiguriert ist, sprich diese Zielplattform nicht hat. Damit könnte auch dieser Konstellation begegnet werden. Ich befürchte allerdings, dass das zu selten benötigt wird, so dass es nicht umgesetzt werden wird.

Die einzige Möglichkeit das herauszufinden ist einen entsprechenden Featurerequest zu erstellen. Ein Bug ist es nicht.

Was du machen kannst:
Rufe msbuild in einem Pre- oder Post-Build Ereignis deiner 64-Bit Exe manuell auf, um die 32-Bit Exe zu erstellen.

[venice2]

Zitat:

Ich habe eine Projektgruppe mit einer Exe und diversen DLLs. Diese kompiliere ich mal für 64-Bit und mal für 32-Bit.

Ist nicht meine ausgangs Situation daher.. sorry fehl am Platz dies als vergleich heranzuziehen.

Zitat:

Ein Bug ist es nicht.

Bin ich anderer Meinung.

Wenn eine Funktion innerhalb der IDE zur Verfügung gestellt wird und diese nicht funktioniert ist es ein Bug.
Ich erhalte nicht umsonst Fehlermeldungen auf Grund meiner Konstellation.

Wenn ich eine Projektgruppe neu erstelle und das nicht Funktioniert btw. auf falsche *.DCU's hin kompiliert wird dann ist das ein Bug.
Kann man drehen und wenden wie man will.

Zitat:

Der Anwendungsfall, dass man eine Abhängigkeit mit einer anderen Bittigkeit hat, dürfte recht selten sein...

Trotzdem ändert es nichts daran das es funktionieren muß.
Tut es das nicht ist es ein Bug.

Zitat:

Das ist schon korrekt so.

Nein ist es nicht.

Kann man aber geteilter Meinung drüber sein.
Es ist nicht das was man eigentlich logischerweise erwartet.

Zitat:

Rufe msbuild in einem Pre- oder Post-Build Ereignis deiner 64-Bit Exe manuell auf, um die 32-Bit Exe zu erstellen.

Es geht nicht um eine lösungssuche oder eine andere Möglichkeit
sondern darum aufzuzeigen das beide Varianten nicht korrekt funktionieren.

Man schaue sich mein Video an.
Mehr ist da nicht zu sagen.

Wenn man versucht das irgendwie zu Entschuldigen, gut kann ich mit Leben
ändert aber nichts an der Tatsache das hier einiges im argen, nicht vollständig\funktionstüchtig ist.

[jaenicke]

Zitat von venice2:

Wenn ich eine Projektgruppe neu erstelle und das nicht Funktioniert btw. auf falsche *.DCU's hin kompiliert wird dann ist das ein Bug.
Kann man drehen und wenden wie man will.

Das liegt daran, dass du (anders als im Standard) keine Platzhalter für die Plattform im Pfad verwendest.

[venice2]

Zitat von jaenicke:

Zitat von venice2:

Wenn ich eine Projektgruppe neu erstelle und das nicht Funktioniert btw. auf falsche *.DCU's hin kompiliert wird dann ist das ein Bug.
Kann man drehen und wenden wie man will.

Das liegt daran, dass du (anders als im Standard) keine Platzhalter für die Plattform im Pfad verwendest.

Das

Zitat:

<Platform Condition="'$(Platform)'==''">Win32</Platform>

ist unproduktiv da beide Projekte im gleichen Binären Order geschrieben werden müssen um die Anwendung testen\ausführen zu können.
Plattform-Pfade machen so keinen Sinn.

Es dürfte auch keine Rolle spielen ob Plattform oder statische Pfade verwendet werden.

Wie himitsu schon hingewiesen hat ist nur von Interesse wo die Dcu's abgelegt\erstellt werden.
Das Problem ist wohl eher das der falsche Compiler verwendet wird wenn ich den DCC64 auf eine 32Bit zu erstellende Anwendung loslasse kann das nur schiefgehen.
Auch das ist ein Fehler(Bug!)

[jaenicke]

Ich meine ja auch den DCU-Ausgabepfad ("Ausgabeverzeichnis für Units"). Der sieht normalerweise bei einem neuen Projekt so aus, eben nicht ohne Grund:

Code:

.\$(Platform)\$(Config)

Wenn du das auch so machst, kann nie eine DCU im falschen Format (x64 / x86) gefunden werden.

Zitat von venice2:

Das Problem ist wohl eher das der falsche Compiler verwendet wird wenn ich den DCC64 auf eine 32Bit zu erstellende Anwendung loslasse kann das nur schiefgehen.
Auch das ist ein Fehler(Bug!)

Wie gesagt:
Es wird die Zielplattform des Projekts verwendet, das du zum Erstellen anklickst, egal was bei den Abhängigkeiten aktuell eingestellt ist.

[venice2]

Zitat von jaenicke:

Ich meine ja auch den DCU-Ausgabepfad ("Ausgabeverzeichnis für Units"). Der sieht normalerweise bei einem neuen Projekt so aus, eben nicht ohne Grund:

Code:

.\$(Platform)\$(Config)

Wenn du das auch so machst, kann nie eine DCU im falschen Format (x64 / x86) gefunden werden.

Zitat von venice2:

Das Problem ist wohl eher das der falsche Compiler verwendet wird wenn ich den DCC64 auf eine 32Bit zu erstellende Anwendung loslasse kann das nur schiefgehen.
Auch das ist ein Fehler(Bug!)

Wie gesagt:
Es wird die Zielplattform des Projekts verwendet, das du zum Erstellen anklickst, egal was bei den Abhängigkeiten aktuell eingestellt ist.

Spielt keine Rolle..
Ob diese

Zitat:

Verzeichnis 1 - MyPhone64_SOP\_src\Win64\Debug
Verzeichnis 2 - MyPhone64_SOP\SOP\_src\Win32\Debug

oder die Pfade verwendet werden.

Zitat:

Verzeichnis 1 = ...\MyPhone64_SOP\_src\_dcu
Verzeichnis 2 = ...\MyPhone64_SOP\SOP\_src\_dcu

Ergebnis bleibt das gleiche.
Es werden die gleichen Fehler wie vorher erzeugt.

Zitat:

Es wird die Zielplattform des Projekts verwendet, das du zum Erstellen anklickst, egal was bei den Abhängigkeiten aktuell eingestellt ist.

Wenn die Zielplattform 64Bit ist aber das zweite Projekt 32Bit in der gleichen Projektgroup dann ist das ein Fehler
sollte 32Bit mit dem 64Bit Compiler kompiliert werden. (Was anscheinend der fall ist)

Aber gut! Bin damit durch da der Fehler von meiner Seite aus nicht behoben werden kann.
Muß dann halt jedes Projekt für sich erstellen ist zwar dumm aber nicht zu ändern.
Kann selber nichts für ein Fehlerhaftes verhalten von Delphi.