release version generieren

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

1

#define DEBUG

2

3

4

....

5

6

int main()

7

{

8

9

  ...

10

#ifdef DEBUG

11

  lcd_out( "bin an Position sowieso" );

12

#endif

13

14

  ...

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

1

#define DEBUG

2

3

#ifdef DEBUG

4

#define DEBUG_OUT(x)  lcd_out(x)

5

#else

6

#define DEBUG_OUT(x)

7

#endif

8

9

10

int main

11

{

12

  ...

13

14

15

  DEBUG_OUT( "bin an Position sowieso" );

16

  ...

17

}

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.

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:

1

#ifndef NDEBUG

2

#define assert(a) ...

3

#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 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:

1

func1()

2

{

3

 bla bla

4

}

5

6

/* eine funktion die für release nicht relevant  // PRIVAT

7

 * ist warum auch immer                          // PRIVAT

8

 */                                              // PRIVAT

9

func2()                                          // PRIVAT

10

{                                                // PRIVAT

11

 bla bla                                         // PRIVAT

12

}                                                // PRIVAT

13

14

func3()

15

{

16

 bla bla

17

}

18

19

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

und dein gesuchtes Programm lautet:

1

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

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.

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