EmBitz: Neu-Kompilierung erzwingen?

[Walter T. (nicolas)]

Hallo zusammen,

ich nutze das klassische EmBitz 1.11 und habe eine Header-Datei, die bei 
jedem Build als neu behandelt werden soll. Sie enthält den 
Revisionsstring.

Wird sie extern geändert (subwcrev) und ist nicht im Editor geöffnet, 
bekommt EmBitz das nicht mit, und im Kompilat ist ein alter 
Versionsstring.

Gibt es einen einfachen Trick?

[Gerald K. (geku)]

Alle Ojektdateien löschen.  rm *.o

[xxx (Gast)]

Menu->build->rebuild all target files?

[Walter T. (nicolas)]

xxx schrieb:
> Menu->build->rebuild all target files?

Gerald K. schrieb:
> Alle Ojektdateien löschen.  rm *.o

Läuft ja beides aufs Gleiche hinaus: Alles neu bauen. Das war genau 
nicht das Ziel. Mit make hätte ich das .o-File über ein force-Target 
erzeugt. Aber es wäre ja irgendwie mit Kanonen auf Spatzen geschossen, 
nur für diesen kleinen Teil den Build-Prozess umzuwerfen.

[Gerald K. (geku)]

Warum nicht ein C-Datei version.c mit dem Inhalt char version[ ]="v2.1";

In die Headerdatei könnt man dann schreiben: extern char version[ ];

[Oliver S. (oliverso)]

Walter T. schrieb:
> Gibt es einen einfachen Trick?

Eine richtige IDE benutzen, die die Abhängigkeiten korrekt beachtet?

Olivet

[Walter T. (nicolas)]

Gerald K. schrieb:
> Warum nicht ein C-Datei version.c mit dem Inhalt char version[ ]="v2.1";
>
> In die Headerdatei könnt man dann schreiben: extern char version[ ];

Stimmt. So herum klappt es. Wenn ich die C-Datei extern ändere, wird das 
im Build-Prozeß berücksichtigt. Wenn ich die H-Datei extern ändere, 
nicht. Das ist irgendwie merkwürdig, aber eine brauchbare Lösung.

[Gerald K. (geku)]

Walter T. schrieb:
> Gerald K. schrieb:
>
>> Warum nicht ein C-Datei version.c mit dem Inhalt char version[ ]="v2.1";
>> In die Headerdatei könnt man dann schreiben: extern char version[ ];
>
> Stimmt. So herum klappt es. Wenn ich die C-Datei extern ändere, wird das
> im Build-Prozeß berücksichtigt. Wenn ich die H-Datei extern ändere,
> nicht. Das ist irgendwie merkwürdig, aber eine brauchbare Lösung.

**Da könne eine Lösung dabei sein** :

https://qastack.com.de/programming/2394609/makefile-header-dependencies

Ich hatte das Problem beim Bilden der Abhängikeit mit einem kleinen 
Hilfsprogramm gelöst. Ist schon lange her, vielleicht finde ich dieses 
Programm mit einer Beschreibung des Problems und dessen Lösung.

Im Internet gibt es eine Lösung mit **SED** :
https://stackoverflow.com/questions/297514/how-can-i-have-a-makefile-automatically-rebuild-source-files-that-include-a-modi?rq=1

Auszug daraus :

$(OBJDIR)/%.d: %.c $(CC) -MM -MG $(CPPFLAGS) $< | **sed** -e 
's,^\([^:]*\)\.o[ ]*:,$(@D)/\1.o $(@D)/\1.d:,' >$@

Mein Hilfprogramm hat die fehlerhafte Abhängigkeitsliste im Nachhinein 
korrigiert.

[Oliver S. (oliverso)]

Gerald K. schrieb:
> Im Internet gibt es eine Lösung mit **SED** :

Da stammt aber aus der Zeit der Lochkarten. Aktuelle Compiler können das 
auch, und aktuelle IDEs nutzen das auch.

Oliver

[Kochstudio (Gast)]

Walter T. schrieb:
> ich nutze das klassische EmBitz 1.11

wäre es dann nicht angebracht ein Ticket beim Hersteller zu eröffnen???

[Frank M. (ukw) (Moderator)]

Walter T. schrieb:
> Wird sie extern geändert (subwcrev) und ist nicht im Editor geöffnet,
> bekommt EmBitz das nicht mit, und im Kompilat ist ein alter
> Versionsstring.

Auch wenn die Datei extern geändert wird, bekommt EmBitz das mit. Das 
klappt hervorragend. Ich mache das sogar sehr oft unter Linux, da mein 
EmBitz-Verzeichnis auf einem Samba-Laufwerk liegt.

Ausnahme: Du hast vergessen, die Header-Datei zum Projekt hinzuzufügen. 
Dann bekommt EmBitz das natürlich nicht mit. Das solltest Du überprüfen.

[Gerald K. (geku)]

Gerald K. schrieb:
> Ich hatte das Problem beim Bilden der Abhängikeit mit einem kleinen
> Hilfsprogramm gelöst. Ist schon lange her, vielleicht finde ich dieses
> Programm mit einer Beschreibung des Problems und dessen Lösung.

%.o: %.c
  $(XCC) -c -o $*.o $(CFLAGS) $<
  @echo $*.o > $*.d
  @$(XCC) -MM  $*.c >> $*.d
  @depcor $*.d

Ein Lösung sofern jemand noch selbst make-files erstellt. Durch 
Verwendung einer IDE, die make-files automatisch erstellt, geht das 
Wissen verloren.

[S. R. (svenska)]

Gerald K. schrieb:
> Ein Lösung sofern jemand noch selbst make-files erstellt.

Ich habe ein solches Konstrukt im Einsatz:

OBJS := main.o uart.o bla.o blub.o
DEPS := $(OBJS:.o=.od)

...

%.o: %.c
        $(CC) $(CFLAGS) -c -o $@ $<
        $(CC) $(CFLAGS) -MM $< > $@d

clean:
        rm -f $(OBJS) $(DEPS) $(MAIN)

...

-include $(DEPS)

Man kann die Abhängigkeiten auch gleichzeitig mit dem Compilerlauf 
erzeugen lassen, aber dazu war ich bisher zu faul.

Wichtig ist die letzte Zeile, in der die Abhängigkeiten eingebunden 
werden. Fehlt eine Datei, ist das kein Fehler - aber dann fehlt auch das 
Objekt, es muss also sowieso kompiliert werden.

[Gerald K. (geku)]

Fatal ist nur, wenn eine Headerdatei geändert wird und das nicht in den 
Code einfließt.
Daher sollte bei Abschluss einer Version **alles** neu kompilieren.

[Oliver S. (oliverso)]

Gerald K. schrieb:
> Daher sollte

man sich bei solch grundlegenden Funktionen 100%-tig auf das 
Build-System verlassen können. Vorausgesetzt, man hat das Projekt 
richtig eingerichtet, muß das richtig gebaut werden.

Oliver