Über Kommandozeile die Abhängigkeiten von Units auslesen

[hs-y]

Hallo Gemeinde,

ich suche ein Tool, was man mit der Kommandozeile ausführen kann, dass einem anzeigt, welche Units in einem Projekt verwendet werden und welche Units die verwendeten Units usw. verwenden. Am besten wäre es, wenn dieses Tool die Pfade in denen die Units liegen mit ausspuckt. Ansonsten reicht es wenn die verwendeten Units ausgegeben werden. Dann muss ich mir ein tool programmieren, was diese sucht.

Icarus oder die ModelMaker Tools sind nciht geeignet, da sie graphische Tools sind.

Viele Grüße

[mjustin]

Zitat:

Zitat von hs-y

Hallo Gemeinde,

ich suche ein Tool, was man mit der Kommandozeile ausführen kann, dass einem anzeigt, welche Units in einem Projekt verwendet werden und welche Units die verwendeten Units usw. verwenden. Am besten wäre es, wenn dieses Tool die Pfade in denen die Units liegen mit ausspuckt. Ansonsten reicht es wenn die verwendeten Units ausgegeben werden. Dann muss ich mir ein tool programmieren, was diese sucht.

Icarus oder die ModelMaker Tools sind nciht geeignet, da sie graphische Tools sind.

Viele Grüße

In diesem Bereich hat Delphi nicht gerade die Nase vorn...

Eine Möglichkeit ist der --doc Schalter (ab Delphi 2005 glaube ich), damit wird für jede Unit und die DPR eine XML Datei erzeugt. Diese kann man dann parsen. Netterweise enthält die XML die zur DPR gehört, eine komplette Liste aller verwendeten Units.

Einziger Haken: man findet so nicht heraus, in welchem Verzeichnis die jeweiligen verwendeten Units liegen, und auch keine Aufrufhierarchie.

Viele Grüße,

[himitsu]

Es gibt ja ein paar Programme dazu, um die [dp]Unit-Abhängigkeiten[/dp] rauszubekommen.
Wenn du lieb fragts, vielleicht bastelt einer davon ja an seinem Programm noch etwas rum.

[mjustin]

Zitat:

Zitat von himitsu

Es gibt ja ein paar Programme dazu, um die [dp]Unit-Abhängigkeiten[/dp] rauszubekommen.
Wenn du lieb fragts, vielleicht bastelt einer davon ja an seinem Programm noch etwas rum.

Ja, das könnte man bei CodeGear ja mal anfragen - die sitzen ja praktisch an der Quelle ;)

[hs-y]

Das mit dem --doc Schalter klingt nun schon wieder ziemlich kompiliziert für meinen Use-Case.

Mir würde eigentlich ein Tool reichen, was in der Konsole jede Unit ausgibt, die verwendet wird.

Die Programme mit den Unit-Abhängigkeiten habe ich bereits gesehen. Das von grizzly auch ausprobiert (allerdings ohne das grafische Tool zusätzlich) was dann nicht funktioniert hat.

[mjustin]

Zitat:

Zitat von hs-y

Das mit dem --doc Schalter klingt nun schon wieder ziemlich kompiliziert für meinen Use-Case.

Na, das ist keine schwierig zu verarbeitende Ausgabedatei, dafür muss man noch nicht einmal einen XML Parser bemühen:

Delphi-Quellcode:

<?xml version="1.0" encoding="utf-8"?>
<namespace name="GUIDemo">
  <contains name="Grids" />
  <contains name="MaskUtils" />
  <contains name="Mask" />
  <contains name="ValEdit" />
  <contains name="BTPrimitiveMap" />
  <contains name="BTThreadSafe" />
  <contains name="BTConsumerID" />
  <contains name="BTOMQInterfaces" />
  <contains name="IndyFunc" />
  <contains name="BTURI" />
  <contains name="BTJMSConnectionFactory" />
  <contains name="DateUtils" />
  <contains name="BTSSLOptions" />
  <contains name="BTTypes" />
  <contains name="ShadowWnd" />
  <contains name="ComConst" />
  <contains name="oleacc" />
  <contains name="ABAccessibility" />
  <contains name="MMSystem" />
  <contains name="ActnCtrls" />
  <contains name="Imm" />
  <contains name="RichEdit" />
  <contains name="ToolWin" />
  <contains name="WideStrUtils" />
  <contains name="Dlgs" />
  <contains name="StdCtrls" />
  <contains name="ListActns" />
  <contains name="ZLib" />
  <contains name="Contnrs" />
  <contains name="ImgList" />
  <contains name="WinSpool" />
  <contains name="Consts" />
  <contains name="ComStrs" />
  <contains name="ShellAPI" />
  <contains name="RegStr" />
  <contains name="WinInet" />
  <contains name="UrlMon" />
  <contains name="ShlObj" />
  <contains name="CommDlg" />
  <contains name="StdActns" />
  <contains name="CommCtrl" />
  <contains name="ActnColorMaps" />
  <contains name="synacode" />
  <contains name="Messages" />
  <contains name="ActiveX" />
  <contains name="ImageHlp" />
  <contains name="StrUtils" />
  <contains name="Math" />
  <contains name="Character" />
  <contains name="RTLConsts" />
  <contains name="SysConst" />
  <contains name="Types" />
  <contains name="synafpc" />
  <contains name="synaip" />
  <contains name="blcksock" />
  <contains name="synautil" />
  <contains name="synsock" />
  <contains name="ActnMan" />
  <contains name="ActnMenus" />
  <contains name="ExtActns" />
  <contains name="Mapi" />
  <contains name="ExtDlgs" />
  <contains name="Buttons" />
  <contains name="ComObj" />
  <contains name="Clipbrd" />
  <contains name="Dialogs" />
  <contains name="ComCtrls" />
  <contains name="ExtCtrls" />
  <contains name="GraphUtil" />
  <contains name="Printers" />
  <contains name="FlatSB" />
  <contains name="HelpIntfs" />
  <contains name="Menus" />
  <contains name="Themes" />
  <contains name="Controls" />
  <contains name="DwmApi" />
  <contains name="ActnList" />
  <contains name="MultiMon" />
  <contains name="UxTheme" />
  <contains name="SyncObjs" />
  <contains name="Graphics" />
  <contains name="Registry" />
  <contains name="IniFiles" />
  <contains name="Classes" />
  <contains name="TypInfo" />
  <contains name="VarUtils" />
  <contains name="Windows" />
  <contains name="Variants" />
  ...
</namespace>

[hs-y]

Okay unter diesen Umständen ist es doch möglich, die Dokumentation zu nutzen.

Werden hier denn alle Units aufgelistet? Also auch die Units, die von den Units des Projektes gebraucht werden?

[Tyrael Y.]

Nur rein Interresse halber....wozu Braucht man so eine Auflistung?
Ich versteh grad nicht den Sinn.

Wenn ich einen Apfel habe, habe ich einen Apfel.
Ob es aus Kohlenhydraten, Zucker, Atomen, Protonen, Mesonen, Leptonen, Quarks, usw. besteht ist doch für die Nutzung irrelevant.

Soll keine Kritik an dem Ganzen sein.
Mich würde einfach nur interressieren wozu so etwas gut ist.

Gruß
Tyrael

Edit: Huch 1000. Beitrag ... :cheers:

[hs-y]

Das ganze hat den Sinn, dass wir ALLE Dateien in einem Versionsverwaltungssystem (in diesem Fall Perforce) haben möchten. Damit keine Dateien vergessen werden, möchten wir so sicherstellen, ob die Units schon im Versionsverwaltungssystem sind, oder diese noch hinzugefügt werden müssen, weil zum Beispiel ein Entwickler neue Komponenten benutzt.

Ich hoffe, das macht den Sinn klarer.

[himitsu]

wobei man diese List auch direkt aus der EXE auslesen kann ... ihr müßt euch nur mal die Resourcen genauer ansehn :)

[add]
Problem ist aber z.B., daß ohne zugehörende Pfadinformationen nicht schergestellt werden kann, ob eine Unit zu Delphi gehört oder nicht.

[hs-y]

Sorry, aber ich habe keine Ahnung wie man das macht. Und ist die EXE nicht normalerweise ein Binary??? Da wird das doch dann schwieriger oder nicht?
[EDIT] Wenn ichs mir recht überlege, wäre es sogar günstiger das ganze aus der EXE extrahieren zu können!

Naja, man kann aber die Suchpfade von Delphi verwenden z.B: {BDS}\lib um einzelne Units zu suchen. Da wird dann die Zahl der Pfade schonmal deutlich begrenzt.

[himitsu]

Auslesen via LoadResource und Co.

PACKAGEINFO (RCData)

[add]
z.B. siehe PACKAGEINFO
> http://www.delphipraxis.net/internal...ht=packageinfo

[mjustin]

Zitat:

Zitat von Tyrael Y.

Nur rein Interresse halber....wozu Braucht man so eine Auflistung?

Ganz einfach: QA (Quality Assurance). Unter diesen Oberbegriff fallen z.B.

- statische Codeanalyse zur Fehlersuche
- Dokumentation
- Statistiken
- Versions- und Konfigurationskontrolle
- Continuous Integration / Buildskripte
- Abhängigkeitsanalyse

Delphi macht QA etwas schwer, da die Metadaten über die Projekte nicht über eine Standard-API ausserhalb von Delphi verfügbar sind. Innerhalb von Delphi kann man mit der OTA (Open Tools API) einige Informationen erhalten. Tools auf Kommandozeilenebene haben es schwer, da man ja z.B. noch nicht einmal die effektiven Source- und Libraryverzeichnisse auf einfache Weise ermitteln kann.

Für kleine Projekte, deren Unitabhängigkeiten der Entwickler noch leicht überschauen kann, braucht man so etwas natürlich nicht (da hat man halt Unit1.pas und Unit2.pas ;-) - bei Projekten, die sich noch in der Entwicklung durch häufiges Refactoring ändern und an denen viele Entwickler (also mehr als einer) arbeiten, ist Qualitätssicherung schon aufwendiger.

Man könnte sich schnell mit einem TRegEx statische Codeanalysetools selber schreiben, um z.B. leere except .. end Blöcke zu finden. Dazu braucht man aber die Verzeichnisse, in denen der Sourcecode liegt. Schon diese Information läßt sich nicht dem Compiler entlocken. Mit MSBUILD gibt es eine Möglichkeit, eine komplette Liste der Suchverzeichnisse zu erhalten - nur hilft dies nicht, wenn in der DPR die Units über relative Pfade eingebunden werden.

Mein Fazit: es wäre für Toolentwickler sehr hilfreich, wenn der Delphi Compiler eine vollständige Liste der verwendeten Units erzeugen könnte, mit Pfadangaben. Dann würde es vermutlich viel mehr Tools geben, insbesondere auch freie / kostenlose Tools, da der (sicher immens hohe) Aufwand für die Abhängigkeitsermittlung entfiele.

Cheers,

[gammatester]

Mit dem --depends-Switch (ab D9) geht's einfacher, es wird ein .d-File angelegt mit den Pfaden. Beispiel:

Code:

D:\DMX\M10\DCC32 -b t_kdf.pas --depends

t_kdf.d t_kdf.exe: t_kdf.pas \
      C:\TEMP\mem_util.dcu \
      C:\TEMP\HMACSHA1.dcu \
      C:\TEMP\SHA1.dcu \
      C:\TEMP\kdf_sha1.dcu \
      D:\DMX\M10\SysInit.dcu \
      D:\DMX\M10\System.dcu

Gruß Gammatester

[hs-y]

Der depends switch ist natürlich genial...
[EDIT]Da ich meine Projekte eh über die Kommandozeile kompilieren möchte ist dies eine sehr gute Alternative. Habe dcc32 so oft benutzt den aber irgendwie immer übersehen. Danke!

[himitsu]

hab grad mal nachgesehn und den scheint es mindestens ab D2006 zu geben (in D7 noch nicht)

[gammatester]

Zitat:

Zitat von himitsu

hab grad mal nachgesehn und den scheint es mindestens ab D2006 zu geben (in D7 noch nicht)

ja, daß ist aber nix neues, da ich in meinem Beitrag schon geschrieben habe, daß es ihn schon in D9 aka D2005 gibt :wink:

[Stevie]

Hi,

ich hab gerade mal dcc32 (von Delphi 2009) mit dem depends switch über ne unit gejagt, aber irgendwie kommt da keine Datei bei raus, welche die Abhändigkeiten auflistet. Die benutzten Units werden alle kompiliert. Hab ich irgendwas übersehen?

Nachtrag: Habs nochmal auf eine dkp losgelassen und siehe da, ich hab eine .d Datei zu diesem Package, welche aber sehr dürftige Abhängigkeiten abbildet (Units die aus anderen Packages kommen, werden nicht gelistet)

MfG

[gammatester]

Bei D9/D10 geht's bei mir auch mit Units, ich nehme mal an für Unit sample.pas gibt's dann ein sample.d (in welchem Verzeichnis? source, dcu, lib??)

Code:

KDF_SHA1.d KDF_SHA1.dcu: KDF_SHA1.PAS \
      C:\BP\SOURCE\43X\CRYPT\HMACSHA1.dcu \
      C:\BP\SOURCE\43X\CRYPT\SHA1.dcu \
      D:\DMX\M9\SysInit.dcu \
      D:\DMX\M9\System.dcu

[mjustin]

Zitat:

Zitat von gammatester

Bei D9/D10 geht's bei mir auch mit Units, ich nehme mal an für Unit sample.pas gibt's dann ein sample.d (in welchem Verzeichnis? source, dcu, lib??)

Code:

KDF_SHA1.d KDF_SHA1.dcu: KDF_SHA1.PAS \
      C:\BP\SOURCE\43X\CRYPT\HMACSHA1.dcu \
      C:\BP\SOURCE\43X\CRYPT\SHA1.dcu \
      D:\DMX\M9\SysInit.dcu \
      D:\DMX\M9\System.dcu

:thumb:

Das sieht sehr gut aus, ich muss gestehen dass ich zwar schon den Schalter kannte, ihn aber nicht ausprobiert habe nachdem ein Delphi-Guru (iirc auf Stackoverflow) schrieb, dass der Schalter seltsamerweise keine Ausgabe erzeugt. Eventuell braucht der Guru mal wieder eine Meditation.

[hs-y]

Es wäre ja cool, wenn dazu noch alle weiteren Abhängigkeiten, wie .dfm etc. angezeigt würden. Aber man will ja nicht zu viel verlangen!