Ja, alle Packages müssen im Suchpfad (PATH) stehen,
denn wenn ein
Package ein Anderes läd, dann über den Suchpfad (denn den Eintrag mit Pfad in der Registry, kennt das dort nicht.
So in "Known Packages" registriert
C:\Pfad\Package1.bpl
C:\Pfad\Package2.bpl
Wobei Package2 das Package1 in seinen Requires drin hat (also als
DLL-Import, wie bei einer
DLL)
Wird erst Packages1 und dann Package2 geladen, ist alles OK,
aber wird zuerst Package2 geladen, dann versucht Windows Package1 zu laden, aber wenn es Dieses nicht in den
DLL-Suchpfaden findet, dann knallt es.
(Besonders schön auch, dass Delphi dann sagt "Package2 wurde nicht gefunden", obwohl Windows meint Package1 sei das Problem)
https://learn.microsoft.com/de-de/wi...y-search-order
Umgebungsvariablen:
Es kann das in dem %PATH% vom System sein (SystemVariables), im %PATH% vom WindowsBenutzer (UserVariables) oder das %PATH% im Delphi (Tools > Optionen >
IDE > Umgebungsvariablen)
z.B. die Compiler-Schalter in der DPK kommen aus der DPROJ, allerdings schwachsinnig die Variante der Basis-Config (wie um Himmels Willen soll der Dreck mit dem IMPLICITBUILDING funktionieren, wenn die falsche Config und falsche sonstige Projektoptionen, wie z.B. Ausgabepfade, verwendet werden)
Und dann noch den Quatsch mit ImpliciteBuilding, weil dort wird nur die DPK benutzt (nicht die DPROJ), wo dann die falsche Config (Basis und nicht das Aktive, wie z.B. Release oder Debug) in der
DPR steht,
sowie auch eingestellte Ausgabepfade fehlen, die aus den Projektoptionen des impliziten Packages.
Wobei es dafür seit Jahren einen offenen Bugreport bei Emba gibt, denn sie bräuchten einfach nur vorm/beim Laden der Packages alle Pfade der registrierten Packages (zumindestens Jene, welche nicht in %PATH% stehen, als
DLL-Suchpfad beim Windows registrieren. (temporär, während der Abarbeitung der Liste, oder einfach permanent)
Hätte also schon seit knapp einem Jahrzehnt behoben sein können.
https://quality.embarcadero.com/browse/RSP-10321