IncludeFile fundamentally flawed?

[Mistrel]

The way IncludeFile/XIncludeFile works is by appending the absolute directory of the main source file to the include file. This will break any includes relative to the file in which it's declared if it's not within the same directory as the main source file.

So if I have a directory structure like this:

Code: Select all

/folder/functions/lib1.pb
/folder/functions/lib2.pb
/folder/functions/lib3.pb
/folder/main.pb

.. where lib1 and lib2 each use XIncludeFile("lib3.pb"), main will fail to compile with an error similar to this:

Line 1: File not found (V:\folder\lib3.pb).

What this means is that .pb files that use either IncludeFile or XIncludeFile are not portable unless no directory hierarchy is used in the project.

I would argue that this method of resolving include files is fundamentally flawed.

This is also unlike the behavior of the C 'quoted form' of the #INCLUDE directive:

[Quoted form] instructs the preprocessor to look for include files in the same directory of the file that contains the #include statement, and then in the directories of any files that include (#include) that file. The preprocessor then searches along the path specified by the /I compiler option, then along paths specified by the INCLUDE environment variable.

[pdwyer]

can you use IncludePath :

IncludePath
IncludePath will specify a default path for all files included after the call of this command. This can be very handy when you include many files which are in the same directory.

So can you put this in between groups of includes in different areas?

[Mistrel]

IncludePath is still relative to the main source file.

[pdwyer]

Oh I see what you mean, this is for nested includes, I hit this in Jan and started this thread http://www.purebasic.fr/english/viewtop ... ed+include it might be of help.

[Mistrel]

The #PB_Compiler_File+"\.." trick does exactly what I want. However I would expect this behavior to be built into the include functions.