[GCC/G++] include paths definieren in broncode

[Arcane Apex]

Ik heb MinGW(GCC/G++) gedownload om wat oude broncode te hercompileren voor Windows.
Echter krijg ik compiler errors omdat G++ de header files niet kan vinden. Nu is dit begrijpelijk, omdat de headerfiles niet in dezelfde map/directory zitten als de main.cpp file en tevens heb ik geen extra flag om naar de header files te verwijzen meegegeven aan G++.
De header files zitten dus in een aparte directory.

Nu is mijn vraag of GCC/G++ uit de include paths in de broncode kan opmaken waar de header files zich bevinden. Zo ja, dan hoef ik enkel paths toe te voegen aan de include statements.

Dit is de huidige verwijzing zonder path:

code:

#include <iostream>

Dit is zoals ik het zou willen hebben, maar ik weet niet of G++ dat zal begrijpen en ik weet niet of ik de syntax hier goed heb:

code:

#include <C:\projecten\app\include\iostream>

Het doel is dus de include statements aan te vullen met een path welke naar de header files verwijst zodat G++ ze kan vinden tijdens het compileren. Heeft iemand enig idee of G++/GCC dit kan en wat de syntax daarvoor is?

[RobIII]

Arcane Apex schreef op donderdag 31 juli 2008 @ 13:14:
Dit is zoals ik het zou willen hebben, maar ik weet niet of G++ dat zal begrijpen en ik weet niet of ik de syntax hier goed heb:

code:

#include <C:\projecten\app\include\iostream>

Heb je 't al gewoon eens geprobeerd? Je weet ook dat je het pad gewoon kan meegeven?

[ Voor 6% gewijzigd door RobIII op 31-07-2008 13:32 ]

[Cascade]

Heb je de handleiding van gcc wel een keer doorgenomen?

Dit is wellicht handig: http://gcc.gnu.org/online...ns.html#Directory-Options

Ik zou niet de volledige paden in je includes gaan zetten, en zeker niet voor standaard C/C++ libs zoals in jouw voorbeeld. Maar het is wel mogelijk.

Heb je wel een project file met al je paden? Een makefile of hoe dat in MinGW geregeld is?

[ Voor 46% gewijzigd door Cascade op 31-07-2008 13:34 ]

[Arjan]

ik weet niet hoe je compileert, maar het lijkt me niet zo lastig om een include directory mee te geven op de commandline?

[Arcane Apex]

Arjan schreef op donderdag 31 juli 2008 @ 13:30:
ik weet niet hoe je compileert, maar het lijkt me niet zo lastig om een include directory mee te geven op de commandline?

De reden is dat ik het zo flexibel mogelijk wil houden en dus ook de optie voor meerdere include directories open wil houden.

[Arcane Apex]

Cascade schreef op donderdag 31 juli 2008 @ 13:29:
Heb je de handleiding van gcc wel een keer doorgenomen?

Dit is wellicht handig: http://gcc.gnu.org/online...ns.html#Directory-Options

Ik zou niet de volledige paden in je includes gaan zetten, en zeker niet voor standaard C/C++ libs zoals in jouw voorbeeld. Maar het is wel mogelijk.

Heb je wel een project file met al je paden? Een makefile of hoe dat in MinGW geregeld is?

Zijn dat geen flags voor de commandline? Die wilde ik juist omzeilen vanwege de flexibiliteit in geval van meerdere include directories.

[ Voor 3% gewijzigd door Arcane Apex op 31-07-2008 13:41 ]

[alx]

Ik snap nog steeds niet waarom je in deze richting zoekt als je gewoon met "-IC:\inc1 -IC:\inc2 -IC:\inc3" meerdere directories aan het include path kunt toevoegen. Dat is ook flexibeler, want die kun je activeren in je build files als er een env var geset is of als een script een bepaald resultaat teruggeeft. Als je dat bij iedere #include in de code moet doen, wordt het een bende en ben je beperkter. Daarom hoort het daar dus ook niet.

[pkuppens]

Verdiep je in makefiles.

Verder is -I. -I./inc geen enkel probleem als parameterset van gcc, om 2 paden mee te geven..

En nu zelf aan de slag.

[Cascade]

Arcane Apex schreef op donderdag 31 juli 2008 @ 13:36:
[...]


Zijn dat geen flags voor de commandline? Die wilde ik juist omzeilen vanwege de flexibiliteit in geval van meerdere include directories.

Dat klopt. Het idee bij de gnu compiler/linker is dat je een zogenaamde makefile maakt waar al je project instellingen in staan. Via dat bestand worden dan de de commandline flags doorgegeven aan de compiler en linker. Je hebt wel kennis nodig van de commandline opties en hoe zo'n makefile werkt... Maar hiermee kan je exact opgeven (en op een centrale plaats, niet verspreid door je sourcecode) welke bestanden met welke include paden moeten werken (verschillende versies van dezelfde header mixen is dan geen goed idee).

[Arcane Apex]

Het is namelijk dat ik met meerdere include sub-directories te maken krijg. Dus bijv. /code/include/dir1 , /code/include/dir2 , /code/include/dir3 etc. Ik weet niet of ik in dat geval gewoon de parent/root include directory in de flags of make file mee kan geven of dat ik specifiek naar elke include subdirectory moet gaan doorverwijzen.
Wanneer er zeer veel include sub-directories zijn en naar elke directory specifiek verwezen moet worden zou het kunnen dat de compile commands zeer lang gaan worden door de vele flags. De make file is een goed idee, maar ik wilde de projecten ook zonder makefile kunnen compileren. (Daarnaast wil ik gebruik maken van relatieve paths naar de include files, zodat de code ook onder Linux/Unix kan compileren)

[Zoijar]

-I/code/include

#include <dir1/xxx.h>
#include <dir2/yyy.h>

[Arcane Apex]

Zoijar schreef op donderdag 31 juli 2008 @ 14:13:
-I/code/include

#include <dir1/xxx.h>
#include <dir2/yyy.h>

Bedankt, dat is precies wat ik wilde weten.

[Soultaker]

Maar doe dat alsjeblieft niet met headers van de standaard library (zoals iostream). Als je compiler die niet kan vinden, is er iets fout gegaan bij de installatie, want die horen standaard in het include path te zitten. Als je daar absolute (of zelfs niet-standaard relatieve) paden voor gaat gebruiken compileert je code gegarandeerd niet meer op andere systemen met een andere directory layout.

[maleadt]

Includen met pad kan je toch mits gebruik van "?

code:

#include "/home/username/test.h"

EDIT: whoops, niet goed gelezen

[ Voor 17% gewijzigd door maleadt op 31-07-2008 16:23 ]

[.oisyn]

Ook met <>. Het verschil tussen quotes en angle brackets is dat bij die eerste óók (eerst) wordt gezocht in de dir van de huidige file en de dir van de file die de huidige file include. Angle brackets doorzoeken alleen de 'opgegeven' include folders.

[ Voor 14% gewijzigd door .oisyn op 31-07-2008 16:48 ]

[MSalters]

Arcane Apex schreef op donderdag 31 juli 2008 @ 13:14:
Nu is mijn vraag of GCC/G++ uit de include paths in de broncode kan opmaken waar de header files zich bevinden. Zo ja, dan hoef ik enkel paths toe te voegen aan de include statements.

Dit is de huidige verwijzing zonder path:

code:

#include <iostream>

Standaard C++ header - moet gewoon werken op alles wat C++ heet.

Dit is zoals ik het zou willen hebben, maar ik weet niet of G++ dat zal begrijpen en ik weet niet of ik de syntax hier goed heb:

code:

#include <C:\projecten\app\include\iostream>

Hoort niet te werken, aangezien \p, \a en \i escape characters zijn. Bovendien wil je zelf geen eigen <iostream> header hebben, je wilt de <iostream> van je eigen compiler gebruiken.

[MSalters]

.oisyn schreef op donderdag 31 juli 2008 @ 16:47:
Ook met <>. Het verschil tussen quotes en angle brackets is dat bij die eerste óók (eerst) wordt gezocht in de dir van de huidige file en de dir van de file die de huidige file include. Angle brackets doorzoeken alleen de 'opgegeven' include folders.

Ik dacht het niet, hoor. Sowieso zegt de standaard erg weinig; de exacte interpretatie van niet-standaard header namen (inclusief namen met / of \ erin) wordt aan implementaties overgelaten.

Maar de claim dat #include "X" alleen de twee directories gebruikt die horen bij de laatste twee files uit de include stack verbaast me. Dus als a.cpp #include b.h #include c,h #include d.h, dan worden alleen de directories van c.h en d.h meegenomen? Welke implementatie is dat?

[Verwijderd]

[...] (eerst) wordt gezocht in de dir van de huidige file en de dir van de file die de huidige file include

is geen claim dat alleen de paden die horen bij de laatste twee files van de include stack gebruikt worden.

Ik kan het hier niet uittesten, maar volgens http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/cpp/Search-Path.html en http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/cpp/Include-Syntax.html wordt bij quotes gezocht in het pad waarin de file geïnclude wordt, daarna in de paden opgegeven door de -iquote optie en als laatst in de paden waarin gezocht wordt bij de angle bracket optie.

[CyBeR]

Arcane Apex schreef op donderdag 31 juli 2008 @ 13:34:
[...]


De reden is dat ik het zo flexibel mogelijk wil houden en dus ook de optie voor meerdere include directories open wil houden.

Hardcoded directories en flexibel, hmm...

[.oisyn]

MSalters schreef op vrijdag 01 augustus 2008 @ 00:49:
[...]

Ik dacht het niet, hoor. Sowieso zegt de standaard erg weinig; de exacte interpretatie van niet-standaard header namen (inclusief namen met / of \ erin) wordt aan implementaties overgelaten.

Maar de claim dat #include "X" alleen de twee directories gebruikt die horen bij de laatste twee files uit de include stack verbaast me. Dus als a.cpp #include b.h #include c,h #include d.h, dan worden alleen de directories van c.h en d.h meegenomen? Welke implementatie is dat?

Sorry, ik schreef het een beetje krom op. Wat ik bedoelde was dat hij wel de hele stack doorzoekt - dus ook de dirs van alle files die indirect die ene file includen.
MS trouwens