Doxygen und Tcl: Montierte proc-calls und call-graph?

[Nick M. (Gast)]

Hi!

So, das Doxygen mit C hab ich jetzt ziemlich gefressen. Die 
Seltsamkeiten die ich hatte sind alle geklärt, ist halt bissl pingelig 
das Doxygen.
Mit den mehr als 2000 Seiten Doku kann ich jetzt jeden einfach 
erschlagen. :-))

Jetzt dokumentiere ich die paar Tcl & Tcl/Tk tools die zum Projekt 
gehören. Im wesentlichen nicht viel anders als bei C. Jetzt gibt es aber 
in Tcl so lustige Konstrukte, die Doxygen (noch?) nicht erkennt:

  append procToCall "DecodeFG" $fg "Type" $type
  if { [info commands $procToCall] != ""} {
    $procToCall $bytes $id
  }

Wenn $fg 1 ist und $type 14 ist, dann ist procToCall "DecodeFG1Type14" 
und die proc wird dann mit den parametern $bytes und $id aufgerufen.
Das Konstrukt spart ein lästig langes case und ist für Tcl-User lesbar. 
Verfechter statischer Sprachen kratzen sich am Kopf.

Wie bring ich Doxygen dazu sowas zu erkennen?

Danke im Voraus!

[Michael Gugelhupf (Gast)]

Nick M. schrieb:
> Verfechter statischer Sprachen kratzen sich am Kopf.

Och, so etwas nannten wir früher computed go-to.

> Wie bring ich Doxygen dazu sowas zu erkennen?

Was soll es denn als Ergebnis liefern? Eine Liste aller Sprungziele ist 
schlecht möglich.

[Nick M. (Gast)]

Michael Gugelhupf schrieb:
> Was soll es denn als Ergebnis liefern?

Ich hätte -ganz naiv- gerne einen caller graph dazu.
Ja, klar, dazu müsste Doxygen den code analysieren (was zu viel verlangt 
ist). Ich wäre eventuell mit einer manuellen Methode zufrieden.

Michael Gugelhupf schrieb:
> Och, so etwas nannten wir früher computed go-to.

Naja, weitere Decoder lassen sich auch problemlos per script nachladen, 
ohne am source was zu ändern. Ich find das recht lustig. Einfach nur 
die Decoder-Proc für den Typen schreiben, der Rest geht automatisch.

[Programmiersprachentheaterintendant (Gast)]

Nick M. schrieb:
> Wie bring ich Doxygen dazu sowas zu erkennen?

auf dem gleichen Weg wie Doxygen C/C++ und andere Sprachen bereits kennt 
und in Zukunft kennen lernen wird: schreibe ein Erweiterungsmodul fuer 
Doxygen (extension) oder erweitere das bestehende.

Da Du hier allerdings mit dem statisch im Quellcode arbeitenden Doxygen 
die dynamische, Laufzeitaufgeloeste Tcl/Tk Sprache beackern willst, 
duerftest Du gegen eine heftige "Begrenzungsschwelle" stossen.

Was meinst Du wohl warum die besseren Tools um Python-Quellcode zu 
beackern ebenso in Python geschrieben sind?
(fuer die aelteren Semester: LISP-Quellcode Tools in LISP X)

M.M.n. kann Doxygen in C/C++ genausowenig indirekt genutzte 
Funktionsadressen (Interrupt Vektoren?) sauber darstellen.
Oder andere "Daten"-gesteuerte Algorithmen wie z.B. das /Strategy 
Pattern/ ...

[Programmiersprachentheaterintendant (Gast)]

Nick M. schrieb:
> Wenn $fg 1 ist und $type 14 ist, dann ist procToCall "DecodeFG1Type14"
> und die proc wird dann mit den parametern $bytes und $id aufgerufen.

Michael Gugelhupf schrieb:
> Was soll es denn als Ergebnis liefern? Eine Liste aller Sprungziele ist
> schlecht möglich.


Naja, die tatsaechlich im Quellcode vorliegende Anzahl solcher procs 
duerfte endlich und eher klein sein, also koennte Doxygen sich erstmal 
nur um diese tatsaechlich vorliegenden kuemmern...

Das setzt jedoch voraus dass kein Quellcode zur Laufzeit (aus anderen 
Daten) generiert und nachgeladen wird  <:-)
Mmmmh... lecker Metaprogrammierung!

[Programmiersprachentheaterintendant (Gast)]

Nick M. schrieb:
> Ich wäre eventuell mit einer manuellen Methode zufrieden.

Fuege also manuell geschrieber Doxygen-Inhalt (inkl. manuell skizziertem 
Diagramm) an genau diese Stelle.

Das Ergibt zwar noch keinen Aufrufgraphen, aber eroertert den da 
wirkenden Code...

[Nick M. (Gast)]

Programmiersprachentheaterintendant schrieb:
> Das Ergibt zwar noch keinen Aufrufgraphen, aber eroertert den da
> wirkenden Code...

Das funktioniert auch so schon richtig. Der call-graph ist korrekt, die 
Parameter hab ich dokumentiert.

Ja, mir ist schon klar, dass mein Wunsch naiv ist. Meine Hoffnung ist, 
dass es Leute gibt, die weniger naiv sind und das irgendwie genial 
gelöst haben. :-)

Programmiersprachentheaterintendant schrieb:
> schreibe ein Erweiterungsmodul fuer
> Doxygen (extension) oder erweitere das bestehende.

Ich schau mal, ob ich was find. Danke für den Tip!

[Bernd K. (prof7bit)]

Du müsstest einen Weg finden bei jeder der auf diese Weise 
aufgerufenen Funktionen manuell zu notieren von wo sie aufgerufen 
wird.

Wenn sich Doxygen dahingehend irgendwie erweitern lässt (keine Ahnung) 
könnte man damit vielleicht mit einem neu einzuführenden Befehl (z.B. 
\calledfrom foo) eine Funktion manuell in den Aufrufbaum einer anderen 
Funktion einfügen.

Vielleicht auch mal als Feature-Request bei Doxygen einreichen, denn das 
könnte auch für andere Sprachen nützlich sein.

[Nick M. (Gast)]

Bernd K. schrieb:
> Du müsstest einen Weg finden bei jeder der auf diese Weise
> aufgerufenen Funktionen manuell zu notieren von wo sie aufgerufen
> wird.

Genau! Leider finde ich sowas nicht in Doxygen.
Ich hab zwar jetzt in den Kommentar jeder dieser procs ein:

# This proc call is assembled at runtime in #DecodeLongL4.

 und damit wird auf die proc DecodeLongL4 verlinkt, aber dem 
caller-graph ist das egal.

Mit so einer Methode könnte ich sehr gut leben.

[Nick M. (Gast)]

Ohje!
Doxygen und Tcl ist echt unterirdisch schlecht.

So was:

 SEPushPop SEPollData SEDefaultAcceptorWithForcedRetransmit

wird nicht richtig erkannt. Doxy sieht zwar den Aufruf von SEPushPop, 
die procs SEPollData und SEDefaultAcceptorWithForcedRetransmit die als 
Parameter übergeben werden nicht.
Die übergebenen procs als solche sind dokumentiert und haben einen 
call-graph, aber der caller-graph der das SEPushPop enthalten müsste 
existiert nicht. Und anders rum genauso.

Oder mach ich da was falsch?
Hat jemand eine config für Doxy das Tcl halbwegs richtig hinbringt?

[Dirk B. (dirkb2)]

Ein

if 0 {
  Aufruf1
  Aufruf2
  Aufruf3
  ....
  Alle möglichen Aufrufe wenn du möchtest
}

innerhalb der Prozedur (am Anfang auch zur innline Doku geeignet) geht.

[Dirk B. (dirkb2)]

Nick M. schrieb:
> So was:
>   SEPushPop SEPollData SEDefaultAcceptorWithForcedRetransmit wird
> nicht richtig erkannt.

Das ist ja so was wie Funktionszeiger in C.
Die werden von Doxygen doch auch nicht erkannt.

[Nick M. (Gast)]

Dirk B. schrieb:
> Das ist ja so was wie Funktionszeiger in C.
> Die werden von Doxygen doch auch nicht erkannt.

Würde ich so nicht sagen.
In:

APP_DynamicTasksTaskInstanceAdd(APP_BTHCITasks, pLTT->destInstance - 1, 
taskBox, false);

wird sehr wohl erkannt dass die Funktion APP_BTHCITasks verwendet wird. 
Im Modul APP_DynamicTasks (das eine Liste von Funktionszeigern hat und 
die aufruft) ist der Aufruf dann verständlicherweise verschwunden. Aber 
das ist ja auch zur Laufzeit und bei einer statischen Analyse unmöglich 
feststellbar.