release version generieren

[tom (Gast)]

Hi Leute,
ich weiss nicht ob das hierher gehört, aber ich würde gerne wissen ob 
Ihr ein tool oder ein script kennt, welches mir die erstellte C/H 
Dateien scant die debug infos löscht und mir somit eine released version 
der Dateien erstellt.

[Karl H. (kbuchegg)]

tom schrieb:
> Hi Leute,
> ich weiss nicht ob das hierher gehört, aber ich würde gerne wissen ob
> Ihr ein tool oder ein script kennt, welches mir die erstellte C/H
> Dateien scant die debug infos löscht und mir somit eine released version
> der Dateien erstellt.

Normalerweise macht man das durch den Compiler selbst

#define DEBUG


....

int main()
{

  ...
#ifdef DEBUG
  lcd_out( "bin an Position sowieso" );
#endif

  ...

mit ein paar zusätzlichen Makros macht man sich dann auch noch das Leben 
leichter

#define DEBUG

#ifdef DEBUG
#define DEBUG_OUT(x)  lcd_out(x)
#else
#define DEBUG_OUT(x)
#endif


int main
{
  ...


  DEBUG_OUT( "bin an Position sowieso" );
  ...
}

durch auskommentieren des
 #define DEBUG
wird dann der ganze Debug-Klapperatismus stillgelegt. Stört ja nicht 
weiter, wenn er weiterhin im Code bleibt. So ist er jederzeit wieder 
zuschaltbar, wenn man ihn braucht.

[tom (Gast)]

ja das is is schon klar aber ich suche nach einer Lösung die genau diese 
debug ausgaben/kommentare usw. komplett raus filtert

[Sven P. (Gast)]

Das macht der Präprozessor.

Warum sollte man die eigentlich herausfiltern wollen?

[Rolf Magnus (Gast)]

tom schrieb:
> ja das is is schon klar aber ich suche nach einer Lösung die genau diese
> debug ausgaben/kommentare usw. komplett raus filtert

Aus dem Quellcode? Wozu?

[tom (Gast)]

um den Code Leserlicher zu machen.
es sind ja nicht nur irgendwelche ausgaben sondern acuh irgendwellche 
funktionen die man z.B. für einen hardwaretest schreibt welche aber in 
der release nichts zu suchen haben usw. deshalb dachte ich muß es doch 
eine Lösung geben wie man ein script drüber laufen lässt welches all das 
herausfiltert und eine datei rausspuckt die nunr die nuotwendigen sachen 
enthält.

[duselbaer (Gast)]

Debug-Informationen sind mehr als nur die Debug ausgaben - da steht auch 
drin an welcher Stelle im Code welche Methode liegt usw.

Unter Windows hast Du für gewöhnlich verschiedene Build-Konfigurationen 
(Debug, Release, MinSize, RelWithDebInfo, ...). Da wählst Du einfach die 
richtige aus und gut ist.

Unter Linux gibt es das Tool "strip", mit dem Du die Debug-Infos 
rauswirfst.

Zu Deinen Log-Makros

Ein Tool kenne ich jetzt konkret keines, aber Du könntest Dir mal 
Boost.Wave anschauen, das ist ein C++ Preprozessor, den man dazu 
benutzen könnte.

Bis denn dann

[Klaus W. (mfgkw)]

Karl heinz Buchegger schrieb:
> Normalerweise macht man das durch den Compiler selbst

Das ist soweit richtig, allerdings noch etwas verbesserungsfähig.

Es gibt ein Makro assert(irgendwas).
Das prüft in einer Debugversion zur Laufzeit die
Bedingung (irgendwas) und gibt bei false eine entsprechende
Meldung nach stderr aus und hält das Programm an - nach
ANSI-Standard zumindest.
In einer Releaseversion wird die Verwendung dieses Makros
komplett wegdefiniert und kostet somit weder Rechenzeit noch
Programmcode. Genial schlicht und genial hilfreich.

Mangels stderr hilft das bei einem MC meist nicht viel und
ist in der avr-libc deshalb nur aktiv, wenn man gleichzeitig
__ASSERT_USE_STDERR definiert hat; vgl. 
http://www.nongnu.org/avr-libc/user-manual/group__avr__assert.html
(Und selbst dann wird bei avr-libc nur die Meldung ausgegeben,
und nichts angehalten - das nur am Rande.)

Falls es definiert wird, hängt nun aber für assert() die Frage,
ob es sich gerade um die Debugversion handelt, nicht am
Vorhandensein von DEBUG, sondern am Nichtvorhandensein von NDEBUG.
Es ist etwa so definiert:

#ifndef NDEBUG
#define assert(a) ...
#endif

Deshalb ist es ausserhalb der AVR-Welt sicher geschickter,
nicht das #define DEBUG auszukommentieren, sondern in
ein #define NDEBUG umzuwandeln. Sonst wird assert nicht
wegdefiniert.

Wie gesagt bei avr-libc meist egal, aber irgendwann
programmiert man vielleicht auch wieder auf einem PC.

---

Zurück zur eigentlichen Frage: das Filtern des Quelltextes
nach DEBUG halte ich auch für sinnlos.
Alleine deshalb, weil man ein Programm irgendwann doch mal
ändern muß. Dann will man das Weggelassene ja ncht händisch
wieder einbauen.

So etwas würde Sinn machen, wenn man den Quelltext hergeben
muß, aber Teile des Programms nicht gerne zeigen würde (sei
es, weil es einem peinlich ist oder weil man dem zukünftigen
Leser das Leben nicht zu leicht machen will).
Aus letzterem Grund hatte ich mal ein Programm an allen Stellen,
die ich nicht zeigen wollte, einen Kommentar "// PRIVAT"
kommentiert. Das waren große Bereiche von erklärendem Kommentar,
Quellenangaben ebenso wie Debugausgaben, die das Verständnis
fördern.
So etwas lässt sich mit normalen Textfiltern leicht
ausblenden (find und fgrep), sodaß man die erleichterte
Version gerne hergeben kann.
So hat der arme Leser weniger Ballast :-)

[tom (Gast)]

maorgen Leute Danke für die Antworten. Aber es geht mir nicht ums 
Auskommentieren sondern eher ums generierung des selben files ohne z.B 
einer funktion oder auch nur kommentaren die für release nicht gedacht 
sind.

bsp: Angenommen eine datei namens foo.c
debug version:
func1()
{
 bla bla
}

/* eine funktion die für release nicht relevant ist warum auch immer*/
func2()
{
 bla bla
}

func3()
{
 bla bla
}

jetzt sollte ein script drüber laufen und mittels parameter entscheiden 
welche Zeilen in die neu erzeugte datei ,die als release erstellt werden 
soll, kommen.
undzwar sollte das ergebnis so aussehen:
relase version:
func1()
{
 bla bla
}

func3()
{
 bla bla
}

[Klaus W. (mfgkw)]

tom schrieb:
> maorgen Leute Danke für die Antworten. Aber es geht mir nicht ums
> Auskommentieren sondern eher ums generierung des selben files ohne z.B
> einer funktion oder auch nur kommentaren die für release nicht gedacht
> sind.

Das macht wie gesagt nur Sinn, wenn du den Quelltext auch hergeben
musst. Aber sei's drum, des Menschen Wille ist sein Himmelreich.

Nach meinem Vorschlag schreibst du dann halt so:

func1()
{
 bla bla
}

/* eine funktion die für release nicht relevant  // PRIVAT
 * ist warum auch immer                          // PRIVAT
 */                                              // PRIVAT
func2()                                          // PRIVAT
{                                                // PRIVAT
 bla bla                                         // PRIVAT
}                                                // PRIVAT

func3()
{
 bla bla
}

// Übrigens: der Auftraggeber ist selten dämlich! // PRIVAT

und dein gesuchtes Programm lautet:

 fgrep -v "// PRIVAT" meinedatei.c > release_src/meinedatei.c

[tom (Gast)]

Vielen Dank das werde ich mal ausprobieren.
Zuletzt noch, gibt es eine möglichkeit das filtern so zu gestallten das 
man das suchwort , in dem Fall PRIVAT, einmal am Anfang und einmal am 
Ende hat
Bsp:

func1()
{
 bla bla
}

/* START:PRIVAT */
/* eine funktion die für release nicht relevant
 * ist warum auch immer
 */
func2()
{
 bla bla
}
/* END:PRIVAT */
func3()                                          {
 bla bla
}

[Klaus W. (mfgkw)]

ja, mit awk statt fgrep.
Da müsste ich mich aber erstmal wieder über awk nachdenken; es gibt
Leute hier die bringen das schneller hin.

Aus Faulheit hatte ich das damals mit fgrep gemacht :-)
Mit einem guten Editor ist das auch nicht schwer zu schreiben.

[tom (Gast)]

Vielen Dank für die Hilfe. Ich wusste garnicht das es auch editoren gibt 
welche die dir bei shell scripten helfen. Kennst du einen?

[Klaus W. (mfgkw)]

Mit dem Editor meinte ich das Arbeiten mit Rechtecken, um z.B.
die übereinanderstehenden // PRIVAT ohne viel Arbeit einzufügen
oder wegzunehmen.

Aber auch eine dezente Unterstützung für Shellskripte kann man im
Editor haben (sowohl zum Editieren als auch laufen lassen und
anwenden auf Bereiche im Text).

In beiden Fällen wie immer beim Editieren: EMACS