Projekt: CDK-Dokumenatation

[emax]

Ich hab' bis eben mal gebastelt.
Wenn Ihr in der Doku mal Abschnit 4.1.1.1 anklickt, seht ihr das Resultat.

Bis denne
emax

[alsuffndruff]

Hallo emax,
wie hast du diese source doku erstellt? Ist mir aus dem Thread nicht ganz
klar geworden. Ich hatte das so verstanden, dass JVision dir dabei hilft, UML Diagramme zu erzeugen.
Wenn es dir um reine Sourcecode Darstellung (bzw. darin browsen) geht,
ist vielleicht doxygen die bessere Wahl. Da bekommst du Klassendiagramme,
Variablen nach diversen Kriteren sortiert etc. Ausserdem ist alles so schön eingefärbt, zwecks Lesbarkeit .

Oder habe ich das jetzt vollkommen missverstanden?


Gruss
alsuffndruff

[emax]

Hallo alsuff...

JVision war ein Vorschlag. Hab ich nicht eingesetzt, ich habe UDO genommen und ein bischen drumrum programmiert.

Doxygen habe ich mir gestern angesehen, scheint nicht schlecht zu sein.

Allerdings hat die Dokumentation, um die es hier geht, einen anderen Fokus. Es geht um die Darstellung von Zusammenhängen, die es Einsteigern erleichtern soll, das CDK in seiner Gesamtheit zu verstehen, und den Aufbau eines Images zu durchschauen.

Insofern sehe ich die Sourcedoku hier nur eine kleine Dreingabe, die das Nachschlagen erleichtern soll. Genau da gibt es allerdings noch eine Menge Haken und Ösen, die im Laufe dieses Threads sicher zutage kommen werden.

Trotzdem danke für den Doxygen-Tip

Bis denne
emax

[real angeschissen]

@emax
Unter http://www.hermanns.net/pub/dbox.html bekomme ich "The page cannot be found".
Kannst Du mal einen Link zu der Draft-Doku posten?

[emax]

Hi!
z.Zt. lade ich eine neue Version hoch. Und weil der Upload auch beu DSL so lahm ist, macht mit die Site immer wieder die Verbindung zu.

Wenn's soweit ist, gibts hier eine Mail.

Sorry.
Bis denne
emax

[emax]

Ich hab' jetzt mal eine Vergleichsdoku für Sourcecodes gemacht UDO vs. doxygen. Aktuell kann man sich die noch nicht ansehen, weil:

Mein Webspace reicht nicht aus, ich brauche zusätzlich 110 MB.

Wer kann mir einen Tipp geben, wo ich das installieren kann.
Also freien Web-Space in dieser Grösse, oder vielleicht hat ja einer den Platz übrig.

Komprimiert sind das 10 MB (zip).

Also her mit den Megabytes...

Bis denne
Ed.

[real angeschissen]

Nur mal so ne Idee: Wie wäre es, wenn Du eine Vergleichsdoku nicht komplett, sondern nur ansatzweise erstellen würdest. Für einen Vergleich braucht man nicht die komplette Sourcecodebasis - Auszüge sind vollkommen ausreichend und Du hast mit dem Speicher kein Problem mehr.
Ich persönlich finde eine automatisch generierte Sourcedoku zwar nett, aber eigentlich eher unwichtig. Sowas kann man dann später tatsächlich als zip auf den Server legen. Viel besser fände ich ein pdf, das die Architektur beschreibt und da kommst Du niemals über 5 MB.

[emax]

Hallo!

Nur mal so ne Idee: Wie wäre es, wenn Du eine Vergleichsdoku nicht komplett, sondern nur ansatzweise erstellen würdest

Genau das hab' ich gemacht: nur u-boot.

und Du hast mit dem Speicher kein Problem mehr

Leider Theorie: auf meinem WebServer hab' ich 10MB, und ein Teil ist schon verbraucht.

aber eigentlich eher unwichtig. Sowas kann man dann später tatsächlich als zip auf den Server legen.

Nochmal Theorie: "später", d.h. wenn's fertig ist, das gibts in so einem Projekt nicht. Ausserdem braucht man so eine Doku vor allem dann, wenn man für Änderungen/Erweiterung was nachsehen will. Im Übrigen schadets ohnehin nicht, eine Crossreferenz zu haben.

Gestern hab' ich mir z.B. mal angesehen, wie ein Plugin mit neutrino interagiert. Habe eine Doku rechnen lassen, und konnte so binnen 10 Minuten nachvollziehen, wie alles zusammenhängt. Und das, obwohlvorher ich _überhaupt_ keine Ahnung hatte, wo ich nachsehen musste.

Plugins schreiben wäre ab heute nur noch Fleissarbeit für mich: die Recherche per Doku hat _mir_ jedefalls enorm Zeit gespart.

Viel besser fände ich ein pdf, das die Architektur beschreibt und da kommst Du niemals über 5 MB

Stimme zu, aber: ein Porsche ist auch besser als ein Astra. Aber noch nicht mal einen Astra zu haben, ist ganz schlecht.

Und weil Du mit der Architekturbeschreibung recht hast: voila, da ist Deine Aufgabe: mach hin!

Mein Fokus ist, ich sags nochmal: ein Überblick, keine akademische Studie. Natürlich wäre es toll, eine UML-basierte Architekturbeschreibung etc. zu haben. Und da wir die nicht haben, und Du da ganz offenkundig den Durchblick hast, geb' hier doch mal ein Statement dazu ab, ob Du sowas erstellen wirst. Das wäre dann auch richtig produktiv, oder?

Bis denne
emax

[emax]

Neues Projekt bei Berlios:

http://tuxbox-cdk-doku.berlios.de

Dort findet ihr zunächst die erste öffentliche pre-pre-alpha version.

Schaut euch mal die Abschnitte 4.1.1.1 und 4.1.1.2 an, und gebt eure Meinungen dazu ab. Davon wird abhängen, wie die Sourcedoku weiter aussehen soll.

ACHTUNG: aus Platzgründen sind alle Doku-Files in *.gz Format, was für meinen Mozilla-Browser null Problem ist, der entpackt online, während des Browsens. . Allerdings weiss ich nicht, wie das unter Windoofs ist, im Zweifel einfach Mozilla für Windows installieren (ist eh' besser, da kann man Werbe-Popups abschalten...)

Was es NOCH nicht gibt:
ein CVS
Downloads
und die ganzen anderen Berlios-Gimmicks. Wird aber Stück für Stück nachgearbeitet.

Bis denne
emax

[real angeschissen]

Mein Fokus ist, ich sags nochmal: ein Überblick, keine akademische Studie. Natürlich wäre es toll, eine UML-basierte Architekturbeschreibung etc. zu haben. Und da wir die nicht haben, und Du da ganz offenkundig den Durchblick hast, geb' hier doch mal ein Statement dazu ab, ob Du sowas erstellen wirst. Das wäre dann auch richtig produktiv, oder?

Ach so, ich wußte nicht genau, wo Dein Fokus liegt. UML ist natürlich keine "akademische Studie", sondern ein stink normaler Weg (in der Insdustrie) um Vorgänge und Systeme zu beschreiben. Ich mache so etwas auch beruflich und weiß daher, dass ein ADD eine zeitaufwendige Sache ist.
Ich werde für das Tuxbox Projekt so etwas auf keinen Fall erstellen, da ich die Software nichtmal im Ansatz kenne und der Zeitaufwand für mich zu groß ist.
Das wäre vielleicht eine schöne Aufgabe für einen Informatikstudenten, der dadurch eine schöne (Semester)Übung zur Vertiefung in die Materie erhält.
Ich habe auch nicht gewußt, was Du unter CDK-Doku verstehst, deshalb bin ich mit meinen ADD Vorschlägen wohl ein bisschen übers Ziel rausgeschossen.
Wie Du schon gesagt hast, eine CDK-Doku (was immer da auch drinsteht) ist besser als gar keine Doku.

Nachtrag:
Aber mit der momentanen Form hab ich so ein paar Probleme. Alle Texte sehen bei mir ungefähr so aus:

‹Â¤Ã¸ ?004001.htmlí˜KsÛ6Çïú3“^BR¯¤n"iƶüj”Úc+í eD.IÄ Ã€ -çÓw J²­ŒÃ›:Õ…’‰Ã¿oX.–½šžÃŽ¿8"§óÏ3rñå`vvH×÷úþt>-o ½n?ÃŒš&å¾ô‹Ã“!«?““}ðý»»;ïnàIûóK?1)ú\J ^hBgÒ½r]©6$•!‹„D Ã’ßóz]¯ßíˆÃ«Ã¢Â¢B‡Â«D¹„

Nochmal Nachtrag:
Sorry, ich sollte erstmal gescheit lesen, bevor ich poste. Also nur zur Info: Der IE kommt mit den gezipten html Seiten nicht klar, Resultat siehe oben.
Der Opera packt es aber.

[Centurio]

Also IE 6.0.2800 Sp1, ... kommt sehr gut zurecht mit dem gezippten.

Mal als "Unbeleckter":

Das UDO-Format kommt IMHO deinem Zweck der Dokumentation näher als das Doxygen-Format.
Im UDO-Format sehe ich auf den ersten Blick eher die Struktur (zumindest der Laie durch die "Verzeichnisse").
Das Doxygen-Format bietet IMHO eher Vorteile für die Seite eines Programmierers, der nicht unbedingt mit diesem Projekt vertraut ist, aber trotzdem mal im Source-Code schauen will, wann, wie wo, was deklariert wurde.

@Emax

Also, ich wäre für das UDO-Format.

centurio

[real angeschissen]

Was ist ein "Unbeleckter"?

[emax]

Zu den gzip-Dateien:

Soweit ich es mittlerweile durchschaue, ist es nicht unbedingt eine Frage des Brwosers, ob *.gz Dateien betrachtet werden können, sondern eine Frage der bekannten Mime-Types.

In Windoofs (sorry, ich kanns nicht lassen) könnte das mit IE5 DANN funktionieren, wenn auch im Datei-Explorer die Endung *.gz mit einer bekannten Anwendung zum Anzeigen verknüpft ist. Ob das im IE oder im Explorer eingestellt wird - fragt mich nicht.

IE-6 scheints ohnehin bereits konfiguriert zu haben. Aber ich sag Euch: nehmt Mozilla oder Opera: da kann man die bekotzen Werbe-Popups unterbinden, und die einschlägigen xxx oder Telekom-Seiten (was für mich die gleiche Qualität ist) können Euch die Kiste nicht mehr mit aufgehenden Fenstern zusch..ssen.

Habe eben eine etwas erweiterte Doku hochgeladen, gibt ein paar neue Seiten (4.1.3/4.1.4/4.3, Kapitel 5 komplett neu bzw. überarbeitet, Anhang erweitert)

Zur Zeit sind die Seiten in html-Format (kein *.gz), ausser den Source-Doku Teilen, die sind immer noch *.gz

@real
Ein unbeleckter ist wohl die demutsvollere Variante zu "IMHO". Ich denke mal, das ich ab und zu ein bischen knurrig geantwortet habe, und centurio sich einfach keinen einfangen wollte.

Ich freu mich über Centurios Feedback, könnte mehr davon brauchen. genau wie er das beschrieben hat, geht mir es auch. Mal abwarten, was noch kommt.

Bis denne
emax

[obi]

u-boot/ppcboot:
----------------------
ist das gleiche in verschiedenen versionen - ppcboot wurde bei version 2.0(?) in u-boot umbenannt, weil er nicht mehr nur ppc booten kann, sondern auch andere prozessoren (arm, x86, ...)

siehe projektseiten ppcboot.sourceforge.net & sourceforge.net/projects/u-boot
(links dorthin waeren auf der seite schoen)

"boot-file" ist ein seltsames wort. ich glaube "second stage bootloader" ist die richtige bezeichnung in der art, wie wir ihn benutzen. er koennte auch den bmon ersetzen, ist jedoch riskant und nicht voll implementiert (speicher init usw.)

busybox:
-------------
ein link zur projektseite waere ebenfalls schoen: http://www.busybox.net

[emax]

Hallo Obi,

die Links setze ich rein.

Der "Second-Stage-Bootloader" macht mächtig Schreibarbeit, hast aber recht, werd ich ändern.

Apropos Link: Ihr könnt auf http://tuxbox-cvs.sourceforge.net bzw. den anderen relevanten Seiten (FAQ etc) gerne ebenfalls aud die Doku verweisen:

file:///home/ed/DBox/doc/bin/html/ger/dbox.html

Ich werde euer Projekt auch natürlich auch bei mir in der Doku verlinken.

emax.

[alsuffndruff]

hallo emax
deine doku ist klasse
ich denke fuer die sourcedoku ist doxygen am besten geeignet. Allerdings spielt,es seine Staerken mit C++ code eher aus.
Du solltest doxywizard verwenden, um die Doxygen Dateien zu erstellen, das vereinfacht die Bedienung von doxygen.

Um das ganze aufzupeppen solltest du dot (Option HAVE_DOT) verwenden, dadurch bekommt man unter anderem einen schnellen (weil grafischen) Überblick darüber, welche Objekte sich hinter diversen Variablennamen verbergen. (siehe Anhang für Klasse CBEBouquetWidget aus dem neutrino sourcecode, hoffe der link funktioniert, Option COLLABORATION_GRAPH) . Mach das mal mit neutrino, dann siehst du was ich meine.


Ich glaube, du hast in deinem Beispiel (u-boot) ausserdem die Optionen
REFERENCED_BY_RELATION und REFERENCES_RELATION (siehe Tab Sorce Browser in doxywizard) nicht enabled. Damit geht dir ein wichtiges Feature verloren, naemlich der Hinweis, von welchen Funktionen/Methoden die beschriebene Funktion/Methode aufgerufen wird (Wird benutzt von ...) bzw. welche diese aufruft (Benutzt ....).

Am sinnvollsten ist doxygen allerdings, wenn der Sourcecode in der entsprechenden Syntax dokumentiert wurde. Ist natuerlich hier nicht der Fall, aber ich denke auch so bringt das schon einiges.

[emax]

@alsuff...

Na das hört man doch gern...

Die Tips zu doxygen sind gut. Ich hatte nur einen "Schnellschuss" gemacht, um mal das Echo zu testen. Werde Deine Tips einarbeiten. Mit dem Speicherplatz könnte es aber schwierig werden, das bischen u-boot verballert schon jetzt im Doxygen-Format rund 25MB.

Zwei Möglichkeiten zur Abhilfe gibt es:

1. Alle html-Datein als *.gz Datei speichern. Gute Browser können damit umgehen, und die Ladezeiten könnten u.U. sogar kürzer werden: da nur die kpmprimierte Datei übers Netz geht, ist der Engpass "Downloadzeit" nicht mehr so ein grosses Problem, lediglich das Entpacken dauert einen Moment. Aktuell bräuchte u-boot beispielsweise so etwa 6MB.

Auf meinem Linux-Rechner (2,7GHZ) werden überigens 1262 (in Worten: eintausendzweihundertzweiundsechzig) ge-gnuzip-te doxygen-html-Dateien (*.gz) in (ACHTUNG!):

real 0m0.698s
user 0m0.170s
sys 0m0.160s

Sekunden entpackt ...........

Geil was?

Von daher wäre die Speicherung als*gz unproblematisch, aber nur ein Aufschub des eigentlichen Problems. Denn auf Dauer könnte es trotzdem eng werden, da es ein Quota auf Berlios gibt. Deshalb Möglichkeit Nr.:

2. Langfristig möchte ich daher eine selbsterstellende Source-Doku zur Verfügung stellen. Ich stelle mir die entsprechende doxygen-Konfigurationsdatei in Verbindung mit einem Makefile vor, bei dem nur noch der Pfad zu den Sources angegeben werden muss, und dann die Doku aktuell auf dem heimischen Rechner gerechnet wird.

Für diejenigen, die sich mit Windoofs und Cygwin herumschlagen müssen, müsste an geeigneter Stelle eine "fertige" Source-Doku zum Runterladen bereitstehen (es sei denn, doxygen gibt es auch für Windoofs, keine Ahnung).

Vorteil bei der selbsterstellenden Doku: hat man seine lokeale CVS-Kopie aktualisiert gemacht, bräuchte man nur "make DoxyDoc" eingeben, und dann Kaffe trinken gehen.

Da Du Doxygen besser kennst als ich, kannst Du mir gerne mal eine Konfiguration für Doxywizard zuschicken.

Trotz Allem muss ich aber ein wenig dämpfen: Priorität hat die Text-Dokumentation, und der fehlt es noch mächtig an Inhalt.

Im Text sind immer wieder "hier fehlt noch was" Textbausteine zu sehen. Ich brauche an diesen Stellen unbedingt die Unterstützung von denen, die dazu jeweils was wissen. Zwar kann ich mir die Sachen zum grossen Teil auch selber zusammensuchen. Aber das schaffe ich momentan zeitlich nicht. Es ist schon Aufwand genug, die Schnipsel, die mir zukommen, in ein leserliches und verdauliches Normal-Benutzer-Format zu bringen, und die vielen Tippfehler rauszumachen, die ich beim Schreiben produziere.

Aber mit dem bisherigen Ergebnis bin ich nicht ganz unzufrieden.

Bis denne
emax

[alsuffndruff]

Hallo emax,
ich halte den Weg, eine selbsterstellende source doku zu erstellen erst einmal fuer richtig und schaue gerne mal, wie sich das machen liesse mit der Einbindung in die makefiles. Ich denke die Verwendung eines config files mit jeweils nur angepassten Pfaden waere das richtige. Allerdings weiss ich nicht, ob doxygen mir da Möglichkeiten bietet oder ob man sich dafuer eigene Scripte schreiben muss (was wahrscheinlich auch nicht so sher das Problem waere)
Allerdings waere es schon mal interessant, ob sich ueberhaupt einer dafuer interssiert (ausser uns beiden ). Vor Sonntag komme ich allerdings nicht dazu.

Prinzipiell:
Möchtest du ueberhaupt Sourcedoku in dein Dokument aufnehmen? Wenn ja, sollte man sich erst mal auf die wichtigen Teile beschraenken und diese gemaess obiger Vorgehensweise einbinden (wie immer das technisch dann genau ablaeuft)

Oder möchtest du das nicht? Dann sollte man sich vielleicht unabhaengig von deiner Doku ueberlegen, welche Teile des cvs Baumes man in die Sourcedoku aufnehmen will.

Nur ein paar Gedanken zum Thema, ich schau am Wochenende mal weiter

EDIT: Ich habe die erzeugte neutrino doku mal auf

http://schnecke.homelinux.org/neutrino/

bereitgestellt. Schau mal rein, hoffe mein server schafft das .

Achso: hier das von doxywizard erzeugte file fuer doxygen (in diesem Beispiel fuer neutrino). Du solltest dot im Pfad haben.

------------------------------- snip ------------------------------

Code: Alles auswählen

# Doxyfile 1.3.4

#---------------------------------------------------------------------------
# Project related configuration options
#---------------------------------------------------------------------------
PROJECT_NAME           = neutrino
PROJECT_NUMBER         = 1.0
OUTPUT_DIRECTORY       = /export/home/ldbox2/software/apps/tuxbox/
OUTPUT_LANGUAGE        = German
USE_WINDOWS_ENCODING   = NO
BRIEF_MEMBER_DESC      = YES
REPEAT_BRIEF           = YES
ALWAYS_DETAILED_SEC    = YES
INLINE_INHERITED_MEMB  = YES
FULL_PATH_NAMES        = YES
STRIP_FROM_PATH        = 
SHORT_NAMES            = NO
JAVADOC_AUTOBRIEF      = NO
MULTILINE_CPP_IS_BRIEF = NO
DETAILS_AT_TOP         = NO
INHERIT_DOCS           = YES
DISTRIBUTE_GROUP_DOC   = NO
TAB_SIZE               = 8
ALIASES                = 
OPTIMIZE_OUTPUT_FOR_C  = NO
OPTIMIZE_OUTPUT_JAVA   = NO
SUBGROUPING            = YES
#---------------------------------------------------------------------------
# Build related configuration options
#---------------------------------------------------------------------------
EXTRACT_ALL            = YES
EXTRACT_PRIVATE        = YES
EXTRACT_STATIC         = YES
EXTRACT_LOCAL_CLASSES  = YES
HIDE_UNDOC_MEMBERS     = NO
HIDE_UNDOC_CLASSES     = NO
HIDE_FRIEND_COMPOUNDS  = NO
HIDE_IN_BODY_DOCS      = NO
INTERNAL_DOCS          = YES
CASE_SENSE_NAMES       = YES
HIDE_SCOPE_NAMES       = NO
SHOW_INCLUDE_FILES     = YES
INLINE_INFO            = YES
SORT_MEMBER_DOCS       = YES
GENERATE_TODOLIST      = YES
GENERATE_TESTLIST      = YES
GENERATE_BUGLIST       = YES
GENERATE_DEPRECATEDLIST= YES
ENABLED_SECTIONS       = 
MAX_INITIALIZER_LINES  = 30
SHOW_USED_FILES        = YES
#---------------------------------------------------------------------------
# configuration options related to warning and progress messages
#---------------------------------------------------------------------------
QUIET                  = NO
WARNINGS               = YES
WARN_IF_UNDOCUMENTED   = YES
WARN_IF_DOC_ERROR      = YES
WARN_FORMAT            = "$file:$line: $text"
WARN_LOGFILE           = 
#---------------------------------------------------------------------------
# configuration options related to the input files
#---------------------------------------------------------------------------
INPUT                  = /export/home/ldbox2/software/apps/tuxbox/neutrino/
FILE_PATTERNS          = 
RECURSIVE              = YES
EXCLUDE                = 
EXCLUDE_SYMLINKS       = NO
EXCLUDE_PATTERNS       = 
EXAMPLE_PATH           = 
EXAMPLE_PATTERNS       = 
EXAMPLE_RECURSIVE      = NO
IMAGE_PATH             = 
INPUT_FILTER           = 
FILTER_SOURCE_FILES    = NO
#---------------------------------------------------------------------------
# configuration options related to source browsing
#---------------------------------------------------------------------------
SOURCE_BROWSER         = YES
INLINE_SOURCES         = NO
STRIP_CODE_COMMENTS    = YES
REFERENCED_BY_RELATION = YES
REFERENCES_RELATION    = YES
VERBATIM_HEADERS       = YES
#---------------------------------------------------------------------------
# configuration options related to the alphabetical class index
#---------------------------------------------------------------------------
ALPHABETICAL_INDEX     = YES
COLS_IN_ALPHA_INDEX    = 5
IGNORE_PREFIX          = 
#---------------------------------------------------------------------------
# configuration options related to the HTML output
#---------------------------------------------------------------------------
GENERATE_HTML          = YES
HTML_OUTPUT            = html
HTML_FILE_EXTENSION    = .html
HTML_HEADER            = 
HTML_FOOTER            = 
HTML_STYLESHEET        = 
HTML_ALIGN_MEMBERS     = YES
GENERATE_HTMLHELP      = NO
CHM_FILE               = 
HHC_LOCATION           = 
GENERATE_CHI           = NO
BINARY_TOC             = NO
TOC_EXPAND             = NO
DISABLE_INDEX          = NO
ENUM_VALUES_PER_LINE   = 4
GENERATE_TREEVIEW      = YES
TREEVIEW_WIDTH         = 250
#---------------------------------------------------------------------------
# configuration options related to the LaTeX output
#---------------------------------------------------------------------------
GENERATE_LATEX         = NO
LATEX_OUTPUT           = latex
LATEX_CMD_NAME         = latex
MAKEINDEX_CMD_NAME     = makeindex
COMPACT_LATEX          = NO
PAPER_TYPE             = a4wide
EXTRA_PACKAGES         = 
LATEX_HEADER           = 
PDF_HYPERLINKS         = NO
USE_PDFLATEX           = NO
LATEX_BATCHMODE        = NO
LATEX_HIDE_INDICES     = NO
#---------------------------------------------------------------------------
# configuration options related to the RTF output
#---------------------------------------------------------------------------
GENERATE_RTF           = NO
RTF_OUTPUT             = rtf
COMPACT_RTF            = NO
RTF_HYPERLINKS         = NO
RTF_STYLESHEET_FILE    = 
RTF_EXTENSIONS_FILE    = 
#---------------------------------------------------------------------------
# configuration options related to the man page output
#---------------------------------------------------------------------------
GENERATE_MAN           = NO
MAN_OUTPUT             = man
MAN_EXTENSION          = .3
MAN_LINKS              = NO
#---------------------------------------------------------------------------
# configuration options related to the XML output
#---------------------------------------------------------------------------
GENERATE_XML           = NO
XML_OUTPUT             = xml
XML_SCHEMA             = 
XML_DTD                = 
#---------------------------------------------------------------------------
# configuration options for the AutoGen Definitions output
#---------------------------------------------------------------------------
GENERATE_AUTOGEN_DEF   = NO
#---------------------------------------------------------------------------
# configuration options related to the Perl module output
#---------------------------------------------------------------------------
GENERATE_PERLMOD       = NO
PERLMOD_LATEX          = NO
PERLMOD_PRETTY         = YES
PERLMOD_MAKEVAR_PREFIX = 
#---------------------------------------------------------------------------
# Configuration options related to the preprocessor   
#---------------------------------------------------------------------------
ENABLE_PREPROCESSING   = YES
MACRO_EXPANSION        = NO
EXPAND_ONLY_PREDEF     = NO
SEARCH_INCLUDES        = YES
INCLUDE_PATH           = 
INCLUDE_FILE_PATTERNS  = 
PREDEFINED             = 
EXPAND_AS_DEFINED      = 
SKIP_FUNCTION_MACROS   = YES
#---------------------------------------------------------------------------
# Configuration::addtions related to external references   
#---------------------------------------------------------------------------
TAGFILES               = 
GENERATE_TAGFILE       = 
ALLEXTERNALS           = NO
EXTERNAL_GROUPS        = YES
PERL_PATH              = /usr/bin/perl
#---------------------------------------------------------------------------
# Configuration options related to the dot tool   
#---------------------------------------------------------------------------
CLASS_DIAGRAMS         = YES
HIDE_UNDOC_RELATIONS   = YES
HAVE_DOT               = YES
CLASS_GRAPH            = YES
COLLABORATION_GRAPH    = YES
UML_LOOK               = NO
TEMPLATE_RELATIONS     = NO
INCLUDE_GRAPH          = YES
INCLUDED_BY_GRAPH      = YES
CALL_GRAPH             = NO
GRAPHICAL_HIERARCHY    = NO
DOT_IMAGE_FORMAT       = png
DOT_PATH               = 
DOTFILE_DIRS           = 
MAX_DOT_GRAPH_WIDTH    = 1024
MAX_DOT_GRAPH_HEIGHT   = 1024
MAX_DOT_GRAPH_DEPTH    = 0
GENERATE_LEGEND        = YES
DOT_CLEANUP            = YES
#---------------------------------------------------------------------------
# Configuration::addtions related to the search engine   
#---------------------------------------------------------------------------
SEARCHENGINE           = NO

--------------------------------- snap...........................

[rasc]

aeh, eine Link der nach localhost forwarded, ist nicht sehr genial... ;-)

[alsuffndruff]

hallo,
stimmt
das mt dem link verstehe ich nicht..
ich schreibe ulr http:blabla /url (naturlich mit eckigen Klammern) aber er zeigt im Ergebnis auf localhost ?????

EDIT: Es war der fehlende / am Ende, sorry.
also hier
http://schnecke.homelinux.org/neutrino/