Hallo, ich schreibe mir momentan eine Klasse für den UART, um sie später einfacher in neue Projekte einbinden zu können. Als Entwicklungsumgebung verwende ich Atmel Studio 6. Der Compiler hat folgende Version: "AVR8/GNU C++ Compiler : (AVR_8_bit_GNU_Toolchain_3.4.0_663) 4.6.2" Ich habe nun in einem Projekt eine Header-Datei (Uart.h) mit der Klassendefinition und den Prototypen der Methoden erstellt, diese inkludiere ich in meinem Projekt. Die Methoden selbst befinden sich in einer cpp-Datei (Uart.cpp), welche ebenfalls die Header-Datei inkludiert. Alle anderen benötigten "includes" sind in der Header-Datei untergebracht. Wenn ich nun in meiner Hauptdatei (nennen wir sie mal main.cpp) den Wert für die Konstante F_CPU definiere und den Header von meiner Klasse inkludiere, bekomme ich die im Betreff enthaltene Fehlermeldung. Macht für mich auch eigentlich Sinn, da so wie ich das verstanden habe, die Datei einfach nur mit kompiliert wird damit der Linker diese Methoden den passenden Prototypen aus der Header-Datei zuweisen kann. Diese Datei sieht also nicht das #define in meiner main.cpp sondern nur alles was in meiner Uart.h steht. Wenn ich nun also F_CPU in Uart.h definiere funktioniert es, wie zu erwarten war. Allerdings müsste ich so bei mehreren Klassen die alle auf diese Konstante zugreifen, aufpassen dass ich alle Header-Dateien angepasst habe. Die Frage ist jetzt, ob es eine Möglickeit gibt, das #define für alle Klassen, sichtbar zu machen? Evtl. in den Toolchain Einstellungen vom Projekt? Ein MAKEFILE scheint es beim Atmel Studio nicht zu geben. Wenn jemand einen Tipp hat würde ich mich freuen Alex
Deine Problembeschreibung verstehe ich zwar nicht so ganz (ein #define vor einem #include sollte eigentlich immer funktionieren), aber am einfachsten ist es, solche globalen defines per Compileroption (-DF_CPU=1600000) zu definieren. Damit bist du sicher, daß alle Sourcedateien den selben Wert bekommem. EIntellen kannst du das in den Projeksettings. Oliver
Hallo, genau das habe ich gesucht. Habe es in den Projekteinstellungen eingefügt und es funktioniert. Danke. Das "Problem" liegt glaube ich am Compiler, so scheint er einfach zu arbeiten. Da ich Uart.cpp, wo das define benötigt wird, ja nicht wirklich inkludiere sondern nur die Header-Datei. Die Datei wird dann nur an der Seite compiliert und der Linker findet dann später die Methoden für die Klasse in diesem Objekt, welches aber außerhalb des Projekts erstellt wurde. So würde ich mir das erklären, kann aber nicht behaupten dass ich den Zusammenhang zwischen Compiler und Linker zu 100% verstanden habe. Deswegen kann ich nicht garantieren, dass meine Erklärung korrekt ist. Alex
Alexander R. schrieb: > Die Datei wird dann > nur an der Seite compiliert Dir ist aber schon klar, daß in der uart Object Datei das F_CPU=... gesetzt ist mit der du die compiliert hast. Ob das dann zu deinem aktuellen Projekt identisch ist weiß keiner ausser dir (vieleicht falls du aufgepasst hast) Wenn der Code von solchen externen defines abhängt, ist es weise, die C Datei im Projekt immer neu zu compilieren. Leute ihr habt doch keine 2000 C Dateien und alte Pentium 400 Rechner, daß das ne halbe Stunde dauert, das geht doch innerhalb des Bruchteils einer Sekunde, so what...
Preprozessor-Anweiseungen wie #include oder #define mache nur eine reine Textersetzung. Compiler und linker bekommen davon nie etwas zu sehen. Wenn du in der main.c ein #define definierst, dann ist das nur in der main.c bekannt, dort aber auch in allen nach der Definition inkludierten header-files. Alexander R. schrieb: > Wenn ich nun in meiner Hauptdatei (nennen wir sie mal main.cpp) den Wert > für die Konstante F_CPU definiere und den Header von meiner Klasse > inkludiere, bekomme ich die im Betreff enthaltene Fehlermeldung. Wenn du main.c kompilierst, kommt keine Fehlermeldung. Die kommt erst bei uart.cpp Oliver
Udo Schmitt schrieb: > Wenn der Code von solchen externen defines abhängt, ist es weise, die C > Datei im Projekt immer neu zu compilieren. Könntest du das näher erklären? Ich suche keinen Workaround, ich möchte schon wissen wie es korrekt gemacht werden sollte. Wenn ihr sagt, es ist sinnvoller das define in der Header-Datei zu setzen, werde ich das tun. Und ja, mir ist bewusst das der Präprozessor nur Text einfügt. Alex
Alexander R. schrieb: > Das "Problem" liegt glaube ich am Compiler, so scheint er einfach zu > arbeiten. Warnings lesen und beachten?
Udo Schmitt schrieb: > Leute ihr habt doch keine 2000 C Dateien und alte Pentium 400 Rechner, > daß das ne halbe Stunde dauert, das geht doch innerhalb des Bruchteils > einer Sekunde, so what... Nun ja, nur weil man mit make etc. nicht umgehen kann, muß man seine Unkenntnis nicht als generell richtig erklären. Immer alles neu kompilieren ist nicht nötig. Ein kleines, einigermassen reales Projekt mit vielleicht 20-30 Sourcedateien, kompiliert unterm avr-gcc mehrere Minuten. Das muß man sich nicht antun, wenn es auch anders geht. Oliver
Alexander R. schrieb: > Udo Schmitt schrieb: >> Wenn der Code von solchen externen defines abhängt, ist es weise, die C >> Datei im Projekt immer neu zu compilieren. > > Könntest du das näher erklären? > > Ich suche keinen Workaround, ich möchte schon wissen wie es korrekt > gemacht werden sollte. 'korrekt' ist immer so eine Sache :-) Die beste Lösung ist es, solche Dinge wie F_CPU in den Projekteinstellungen zu definieren. Denn diese Projekteinstellungen werden dem Compiler immer mitgegeben, wenn er ein C-File compiliert. Der Nachteil davon ist allerdings, dass man die Projekteinstellungen als Teil des 'Source-Codes' ansehen muss. Denn wenn man sich nur die C-Files bzw. Header-Files ansieht, dann findet man da ja nicht raus, welcher Wert für F_CPU vorgesehen war. Normalerweise ist das ja auch kein Problem. Es wird nur dann zum Problem, wenn man das Entwicklungssystem wechselt. Denn die C-Files/H-Files kann man, weil reine Text-Dateien, einfach direkt in die neue Entwicklungsumgebung übernehmen. Aber die Projekteinstellungen kann man normalerweise nicht so einfach übernehmen. > Und ja, mir ist bewusst das der Präprozessor nur Text einfügt. Was dir scheinbar noch fehlt, ist die Erkentnis, dass JEDES C-File für sich alleine compiliert wird. Wenn der Compiler main.c compiliert, dann kennt er nur die Dinge, die in main.c geschehen. Plus natürlich die Dinge, die über die Projekteinstellungen dem Compiler beim Aufruf mitgegeben werden Wenn der Compiler uart.c compiliert, dann kennt er nur die Dinge, die in uart.c geschehen. Plus natürlich .... Jedes C-File wird für sich alleine compiliert und wenn der Compiler ein anderes C-File compiliert, dann fängt alles wieder bei 0 an. C kennt keine 'Projekte', so wie das zb in C# der Fall ist, wo der Compiler darauf darauf angewiesen ist, quer über alle Source Code Files Querverbindungen herzustellen. In diesem Sinne ist C minimalistisch. Ein File - ein Compileraufruf - ein Ergebnis. Und erst wenn alle Einzelteile cmopiliert sind kommt dann der Linker und baut aus den vorübersetzten Einzelteilen das Komplettprogramm zusammen.
Oliver S. schrieb: > Nun ja, nur weil man mit make etc. nicht umgehen kann, muß man seine > Unkenntnis nicht als generell richtig erklären. Immer alles neu > kompilieren ist nicht nötig. Ist es nicht, aber um 3 Sekunden (oder 0,3?) zu sparen sich mit Make ins Knie zu schießen und evt. stundenlang Fehler zu suchen ist auch nicht schlauer. Und man kann sich mit Abhängigkeiten oder nicht angegeben Abhängigkeiten wunderbar ins Knie schießen. Oliver S. schrieb: > Das muß man > sich nicht antun, wenn es auch anders geht. Die Frage ist obs anders geht, wenn er eine lib dazulinkt, die abhängig von einem define ist, das je Prozessor oder gar individuellem Projekt (F_CPU) unterschiedlich ist. Oliver S. schrieb: > Ein kleines, einigermassen reales Projekt mit vielleicht 20-30 > Sourcedateien, kompiliert unterm avr-gcc mehrere Minuten. Ist das wirklich bei einem modernen Rechner so lahm? Alexander R. schrieb: > Ich suche keinen Workaround, ich möchte schon wissen wie es korrekt > gemacht werden sollte. jedes C File das von defines abhängt, die je nach Projekt unterschiedlich sein können, musst du zwingend neu compilieren, sonst ist dein Programm inkonsistent. Ob du das 'schlau' über make und Abhängigkeiten machst oder 'dumm' mit "build all" ist erst mal egal. Globale Defines würde ich wie beschrieben über eine gemeinsame Compileroption machen, die für alle compiles benutzt wird. (Batch script, make, wie auch immer)
Udo Schmitt schrieb: > Ist das wirklich bei einem modernen Rechner so lahm? Ist es. make etc. gibt es nun seit Anbegin der Zeitrechnung, heutzutage sogar versteckt hinter der IDE. Das funktioniert. Oliver
Oliver S. schrieb: > make etc. gibt es nun seit Anbegin der Zeitrechnung, heutzutage sogar > versteckt hinter der IDE. Das funktioniert. Und es gibt auch Tools, die die Abhängigkeiten selber bestimmen. Funktionieren ebenfalls. Und Hand aufs Herz: Wenn man den Make-Mechanismus einmal durchschaut hat, ist er nicht schwer zu benutzen. Auch für ganz andere Dinge, als den C-Compiler anzuwerfen :-) (Wer je in der Steinzeit mit PLINK ein Exe zusammenbauen musste, bei dem die Funktionen in Overlays sich denselben Speicher teilen mussten, der kann über das Thema Make oder Nicht Make nur müde lächeln. Da bist du tatsächlich Stunden bzw. Tage dabei gesessen und hast mit Memory Maps die Overlays ausgetüftelt, welche Funktion in welchem Segment sein muss, damit sie a) aufrufbar ist und b) nicht zuviele Page Swaps passieren)
Karl Heinz Buchegger schrieb: > Die beste Lösung ist es, solche Dinge wie F_CPU in den > Projekteinstellungen zu definieren. Denn diese Projekteinstellungen > werden dem Compiler immer mitgegeben, wenn er ein C-File compiliert. Im Atmel Studio 6 habe ich noch keine Option für die Frequenz gefunden. Ist der Eintrag im -D Parameter das Gleiche? > Was dir scheinbar noch fehlt, ist die Erkentnis, dass JEDES C-File für > sich alleine compiliert wird. Soweit ich dass verstanden habe, produziert der Compiler von jeder Datei erst ein Objekt, danach fügt der Linker es zu einem Komplettprogramm zusammen. Dass ist jedenfalls das, was in meiner Vorlesung mal beiläufig erwähnt wurde und was ich mir dann eher aus meinen Büchern zusammen gesucht habe. Das mit den Projekteinstellungen ist ein guter Punkt, da ich nicht gewährleisten kann, dass jemand die gleiche IDE benutzt. Um also alle nötigen Informationen im Quelltext mitzuliefern, scheine ich nicht drum herum zu kommen, das F_CPU in der Header-Datei der Klasse zu definieren. Achso, ich benutze "Make all" im Atmel Studio, das sollte dann jede Datei im Projekt kompilieren. Nur zur Vollständigkeit, weil es hier öfters erwähnt wurde.
Karl Heinz Buchegger schrieb: > nd es gibt auch Tools, die die Abhängigkeiten selber bestimmen. > Funktionieren ebenfalls. > > > Und Hand aufs Herz: Wenn man den Make-Mechanismus einmal durchschaut > hat, ist er nicht schwer zu benutzen. Und ich kenne den häufigsten Tipp von Kollegen wenn seltsames passiert: "Mach mal ein komplettes Rebuild" Wenn das make hinter einer funktionierenden IDE versteckt ist die sauber alle Abhängkeiten aktuell anpasst dann ja. Wenn das aber eine mehr oder weniger 'manuelle' toolchain ist wo man handisch im make rumeditiert, dann sit ganz schnell ein neues h File bei den Abhängigkeiten vergessen. Und wie gesagt, wenn ein komplettbuild nur ein paar Sekunden dauert, wofür? Das ist dann genauso wenig sinnvoll wie wenn jemand versucht im Code ein paar µs Zeit zu sparen, und der Code dann für Benutzerinteraktion ist wo sich der Prozessor zu 99,99% langweilt. Meine Erfahrung mit großen C Projekten (PC über 1000 Sourcen und H Files), allerdings schon Jahre her.
Udo Schmitt schrieb: > Und wie gesagt, wenn ein komplettbuild nur ein paar Sekunden dauert, > wofür? Weil kein reales Projekt, das über ein Anfänger-"Hello world" hinausgeht, in ein paar Sekunden vollständig kompiliert. Alexander R. schrieb: > Das mit den Projekteinstellungen ist ein guter Punkt, da ich nicht > gewährleisten kann, dass jemand die gleiche IDE benutzt. Ok, das ist ein Grund, die IDE-Projekteinstellungen nicht zu nutzen. In dem Fall empfiehtl sich z.B eine header-Datei "global_defines.h" (oder so), in der solche globalen Dinge definiert werden, und die du dann in jedes header-File deines Projektes inkludierst. Oliver
Oliver S. schrieb: > Weil kein reales Projekt, das über ein Anfänger-"Hello world" > hinausgeht, in ein paar Sekunden vollständig kompiliert. Unser Großprojekt in der Firma bestand aus über 400 Sourcefiles, zum Teil bis über 200K groß, etwa 200 h files und compilierte KOMPLETT auf einem 400 MHz PC (>10 Jahre her) in etwa 40 min, mit einem 1600+ AMD Prozessor des nächsten Rechners dann etwa 10-15 min. Jetzt erzählst du mir ein µC Projekt mit ein paar kByte Code braucht euf einem 3 GHz Rechner mehrere Minuten. War jetzt der alte Microsoft Compiler so genial gut, oder sind die Compiler für den AVR so scheiße???? Ich kanns nicht ganz glauben, muss es wohl aber. Ich programmiere hier praktisch ausschlisslich Java, und mit einem Core I7 Rechner dauert das complette rebuild von Projekten mit um die 100 Sourcen auch nur < 1Minute, ein Ant komplettbuild mit Tests und Build von War Files (zum teil sogar umpacken includierter jars und Wars )im Bereich von 1 - 4 Minuten.
Alexander R. schrieb: > Karl Heinz Buchegger schrieb: >> Die beste Lösung ist es, solche Dinge wie F_CPU in den >> Projekteinstellungen zu definieren. Denn diese Projekteinstellungen >> werden dem Compiler immer mitgegeben, wenn er ein C-File compiliert. > > Im Atmel Studio 6 habe ich noch keine Option für die Frequenz gefunden. > Ist der Eintrag im -D Parameter das Gleiche? Ja, ist dasselbe. Im alten AVR-Studio gabs dafür ein eigenes Edit-Feld, aber letzten Endes mündete das auch in einem -DFCPU=.... welches dem Compiler mitgegeben wird.
Alexander R. schrieb: > Um also alle nötigen Informationen im Quelltext mitzuliefern, scheine > ich nicht drum herum zu kommen, das F_CPU in der Header-Datei der Klasse > zu definieren. Das wiederrum ist keine so gute Idee. Da ist es noch besser, ein globales Header-File zu machen, das zwingsweise von jedem includiert werden muss. Und wenn der include vergessen wurde, dann beschwert sich der Compiler, dass er F_CPU nicht kennt. Was du erreichen willst: Egel wieviele C-Files du im Projekt hast, du willst nur an einer einzigen Stelle die Definition von F_CPU physisch haben. Denn nur so ist 100% gewährleistet, dass tatsächlich alle C-Files mit demselben Zahlenwert arbeiten. Hast du im Projekt mehrere Definitionen verstreut, besteht immer die Gefahr, dass diese nicht zusammenstimmen. Und dagegen kann dich ausser dir selber (und deinem Gedächtnis) niemand schützen. Das mag dir heute noch nicht als Prpblem erscheienen, aber wenn du in 2 Jahren das Projekt noch mal vorkramst um es auf eine andere Schaltung mit anderer Taktfrequenz umzustellen, darfst du dann nicht vergessen ALLE F_CPU Definitionen anzupassen. Und wie das halt so ist ... als Mensch macht man Fehler und vergisst bzw. übersieht Dinge gern. Genau aus dem Grund bin ich auch kein Freund der Methode ....
1 | #ifndef F_CPU
|
2 | #define F_CPU 1000000UL
|
3 | #endif
|
..., meinetwegen noch mit einer Warnung garniert (die eh keiner liest). Wenn F_CPU fehlt, dann sollte man das IMHO ruhig mit einem Error quittieren und keine Standardannahmen treffen, die dann ohnehin nicht stimmen und in Fehlersuche ausarten.
Udo Schmitt schrieb: > Oliver S. schrieb: >> Weil kein reales Projekt, das über ein Anfänger-"Hello world" >> hinausgeht, in ein paar Sekunden vollständig kompiliert. > Unser Großprojekt in der Firma bestand aus über 400 Sourcefiles, zum > Teil bis über 200K groß, etwa 200 h files und compilierte KOMPLETT auf > einem 400 MHz PC (>10 Jahre her) in etwa 40 min, mit einem 1600+ AMD > Prozessor des nächsten Rechners dann etwa 10-15 min. Das Projekt, an dem ich zur Zeit bin, compiliert des Nachts auf einem eigenen Compile-Server komplett durch. Dauer: ungefähr von halb 1 Uhr morgens bis knapp nach 5. Wir haben extra eine Mehrkern-Maschine dafür abgestellt, denn ein einziger Kern hat es in einer Nacht alleine nicht mehr geschafft :-) (Ist aber kein AVR-Projekt - sollte aber klar sein :-)
Karl Heinz Buchegger schrieb: > Das Projekt, an dem ich zur Zeit bin, compiliert des Nachts auf einem > eigenen Compile-Server komplett durch. Dauer: ungefähr von 2 Uhr morgens > bis knapp nach 5 Glaube ich dir gerne :-) Wenn ich alle Compiles für alle Betriebssysteme, Rechner und Datenbanken dazunehme, komme ich bei uns auch auf Zeiten > 8h pro Nacht (Ohne Tests). Ich wollte damit nur deutlich machen, daß ich es kaum glauben kann daß es bei modernen Rechnern lohnt für 8Bit µCs keine Komplett Builds laufen zu lassen. Speziell Anfänger, die das halt nur hobbymäßig betreiben können mit nur halb verstandenen make skripten in wunderbare Fallen laufen.
Karl Heinz Buchegger schrieb: > Was du erreichen willst: Egel wieviele C-Files du im Projekt hast, du > willst nur an einer einzigen Stelle die Definition von F_CPU physisch > haben. Denn nur so ist 100% gewährleistet, dass tatsächlich alle C-Files > mit demselben Zahlenwert arbeiten. Genau das war das Ziel. Habe deswegen, wie Oliver S. vorgeschlagen hatte, eine Datei global_definitions.h erstellt und inkludiere sie nun in meinen Header-Dateien. Ich danke euch allen für eure Hilfe. Alex
Udo Schmitt schrieb: > Ich wollte damit nur deutlich machen, daß ich es kaum glauben kann daß > es bei modernen Rechnern lohnt für 8Bit µCs keine Komplett Builds laufen > zu lassen. Ne ne, das passt schon. 2 Punkte: * zum einen, meine Meinung, sollte man sich schon an gewisse Standards halten. Hilft nichts - in der Programmierung muss man eben vieles lernen. * zum anderen hilft dir ein Make All auch dann nicht, wenn du mehrere sich widersprechende F_CPU im System hast. Und das ist für mich eigentlich einer der wichtigeren Punkte in diesem Thread. Ob ein Make All jetzt 20 oder 30 Sekunden dauert (weil die Ausgabe der Fehlermeldungen so langsam ist) ist hingegen zweitrangig.
Tja, das Thema mit make :-) Ich hab mich mal 3 Tage intensiv damit beschäftigt und ein, meiner Meinung nach, gutes und durchdachtes makefile erstellt. Dieses dient mir immer als Vorlage für neue Projekte. Abhängigkeiten werden dynamisch bestimmt, sollte klar sein. Sowas per Hand zu pflegen geht gar nicht :-) Mittlerweile klappt das bei mir besser als in der Firma. Da ist in der Tat manchmal ein build-all nötig weil der Linker ein Symbol nicht auflösen kann (das eigentlich garnicht mehr vorhanden wäre, hätte der Compiler das Objekt neu angelegt). Damit kompiliere ich eigentlich für sämtliche Plattformen mittlerweile. Egal ob embedded, Kommandozeile, QT-Gui... Ein absolutes no-go sind für mich IDE-spezifische Projekteinstellungen. Ich war es leid, jedesmal wieder die passende IDE mit den passenden PlugIns zusammenzubasteln und die Einstellungen durchzugehen. Ich bin der Meinung, ein C oder C++ Projekt sollte sich mit einem Aufruf von make erstmal kompilieren lassen. Diese strikte Trennung von IDE und eigentlichen Sourcen halte ich für sehr wichtig. Die GNU-Toolchain wirds auch dann noch geben wenn Borland, MS oder Eclipse lange Geschichte sind (Achtung, Satz enthält wagemutige Prognosen!). Mich hindert trotzdem nichts daran, Eclipse zu benutzen. Ganz im Gegenteil, finde ich super. Aber ich bin zu keinem Zeitpunkt von Eclipse (oder dem AVR-Plugin) abhängig. Aber ich schweife ab. Im makefile können dann nach Belieben Vereinbarungen getroffen werden, die für das komplette Projekt gelten, wie eben F_CPU. Zur Not eben die Lösung mit dem Zentralen Header-File. Sowas ist eigentlich garnicht aufwändig, meist hat man eh einen extra Header für z.B. Typen wie uint8. (Ich mappe den zB auf uint8_t aus den AVR-Headern. Aber vielleicht hab ich mal eine Toolchain ohne eingebauten uint8_t).
Wenn man Code für den AVR weitergibt, kann man das Definieren von F_CPU imo guten Gewissens demjenigen überlassen, der ihn benutzt. Das heißt, es sollte allgemein bekannt sein, dass man F_CPU definieren muss. Ob derjenige das dann in seinen Projektoptionen macht oder lieber ein #include config.h im Code ergänzt, sei ihm überlassen. Ich würde aber keinen Defaultwert vorgeben, denn der muss ja nicht der tatsächlichen Taktfrequenz entsprechen. Und dann kann man lange den Fehler suchen ...
Udo Schmitt schrieb: > Und ich kenne den häufigsten Tipp von Kollegen wenn seltsames passiert: > "Mach mal ein komplettes Rebuild" > > Wenn das make hinter einer funktionierenden IDE versteckt ist die sauber > alle Abhängkeiten aktuell anpasst dann ja. Eine IDE brauchst du dafür gar nicht. Wie schon Karl Heinz sagte, gibt's für die Abhängigkeiten Tools. Eins davon heißt gcc. Der kann nämlich selber entsprechende Regeln für make erzeugen, die alle include-Abhängigkeiten beinhalten. > Und wie gesagt, wenn ein komplettbuild nur ein paar Sekunden dauert, > wofür? Ich bin jemand, der immer in sehr kleinen Schritten programmiert. Also ein paar Zeilen ändern, neu bauen und ausprobieren. Da ist es wichtig, daß der 2.Schritt möglichst kurz ist, denn das ist Zeit, die ich einfach wartend vor dem PC sitzen muß. Da nerven auch 10 Sekunden schon. Udo Schmitt schrieb: > Ich programmiere hier praktisch ausschlisslich Java, und mit einem Core > I7 Rechner dauert das complette rebuild von Projekten mit um die 100 > Sourcen auch nur < 1Minute, ein Ant komplettbuild mit Tests und Build > von War Files (zum teil sogar umpacken includierter jars und Wars )im > Bereich von 1 - 4 Minuten. Und du findest es akzeptabel, nach jeder winzigen Änderung zum Testen 4 Minuten zu warten, bis der komplett-Build fertig ist? Ich nicht.
xfr schrieb: > Ob > derjenige das dann in seinen Projektoptionen macht oder lieber ein > #include config.h im Code ergänzt, sei ihm überlassen. Es sollte allerdings an einer Stelle sein, an der man es schnell findet. Da ist mir ein globales headerfile mit aussagekräftigem Namen lieber, als eine Definition im makefile. Denn auch make ist nicht gleich make. Wer das Projekt lieber in einer IDE mit automatisch erzeugten makefile nutzen will, muß sich mühsam die defines aus dem makefile suchen. Mit einem header funktioniert das immer und überall. Oliver
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.