PureBasic Forums - English

I opened up a project I wanted to look at to see where I was with it, that I haven't touched for a long time..

The first thing I needed to do was update GridControls to the latest version, which I took care of doing, but now for some reason, I get compile errors that have to do with include paths in the actual GridControls files, as it relates to my project.. I'm not sure what else could have changed but I don't know how to resolve this issue, short of keeping a local copy of GridControls in my project's local directory - which I don't really want to do.

To my knowledge this program compiled flawlessly before I updated to 5.21 LTS, so I'm not sure what could have changed.


Here is the local directory structure
It seems that the IDE or Xinclude statement does not want to references paths outside of the local level, even if I try to add "..\" type prefixes to "back out" of the directory..

I don't recall if I initially had this problem when setting up this structure, and if I did, how I would have solved it..

What I want to do be able to do is reference include files from a single base directory, without having to hard code path locations into include statements (for obvious reasons)

It should be worth noting, that these lines appear to be fine However the problem comes within the tbox.pbi file which has includes that reference Esgrid and a couple other things, and at that point, it appears to be trying to resolve the include path from inside my local project folder. so its looking for directories/files which do not exist inside my project folder.

I can get it to compile by adding "\purebasic projects\includes\gridcontrols\" to the front of every Xinclude within the GridControls source files, but this seems sub-optimal to me, and a pain to have to do anytime srod updates the sources.

> It seems that the IDE or Xinclude statement does not want to references paths outside
> of the local level, even if I try to add "..\" type prefixes to "back out" of the directory

I don't know about XInclude, but I use IncludeFile with "..\" all the time with no problem.

Parenthesis ?
What is that, a macro ?

Zach wrote: To my knowledge this program compiled flawlessly before I updated to 5.21 LTS, so I'm not sure what could have changed.

If that is true what follows probably does not solve your problem, but in case you are wrong and it's not something introduced with 5.22 here it goes anyway:

To make includes relative to each file and have all ALWAYS working from EVERYWHERE and for EVERYONE, I just use this
which makes PB Includefile statement work as it should have from the start, I don't know why Fred decided to make the PB Includefile relative to the main file instead of the file containing the Includefile statement, to me it was a really bad choice and the command, without using #PB_Compiler_FilePath, is practically unusable for anything beyond the simplest scenario.

http://www.purebasic.fr/english/viewtop ... 21#p367921

The use of Includepath to work around the original problem of Includefile just adds to the confusion and make hard to track down how a complex include system is working (when it is working) especially if using includes made by others.
I never, ever use it. I think everyone should just use the method above (#PB_Compiler_FilePath), and you should change to that effect any code made by others you want to use.
This is one of the things I would definitively change about PB without remorse even if it will break code.

http://www.purebasic.fr/english/viewtopic.php?p=268111

It's really bad as it is now IMO, the first time I encountered this I was *flabbergasted* and briefly panicked until I thought (or read, I don't remember) about using #PB_Compiler_FilePath.

luis wrote:

Code: Select all

XIncludeFile  ("..\includes\Kill_Debug_Window.pbi")

Parenthesis ?
What is that, a macro ?

No. It's a strange habit I picked up from somewhere, probably another programming language and I tend to use it as it looks aesthetically pleasing to me. Its just an include statement. And they don't seem to influence it or cause bugs in any way, as I've tested it by removing all of them.


This must be some sort of IDE/compiler bug with path parsing.... or a VERY poor design choice

I tried your solution, and it generates the same error as when I manually tried to reference paths by backing out of directories. i.e "..\path\to\file.pbi"
(there is an errant backslash at the start of the paths, but even removing that does not change anything, just removed the double backslash from the path with same error)


This is what I had to do to make it work


Sort of like was mentioned in one of the posts you linked, it seems to be forcefully appending the project path into the include path, even though it shouldn't be (IMHO)

Here is a set of includes from an actual project file, in the project directory that work fine / back out fine..



This is all so stupid.. Includes from within the projects parent directory work, even when you back out to navigate to a directory with shared resources... but resources that include their own files from their own local directory tree are broken

Also, for those wondering. Include vs Xinclude makes no difference in the error, but I prefer Xinclude because I consider it safer for avoiding redundant includes on accident.

I don't believe manually setting an IncludePath is the correct work-around for this issue, either, like has been suggested in the past. It will just create more headaches as you have to try and keep track of where you are using the statement in all your project files, and at that point you might as well hard-code the paths. But both solutions kind of defeat the purpose of keeping the include code simple and portable, allowing it to adjust to changing directory structures that may be above them.

I wonder if we shouldn't file a bug report... since a feature request didn't work seemingly 3 years ago

Zach wrote: I tried your solution, and it generates the same error as when I manually tried to reference paths by backing out of directories. i.e "..\path\to\file.pbi"

You are not using it correctly.
The path for tBOX.pbi is "C\PureBasic Projects\Includes\GridControls\tBOX\"

If you append "\EsGRID" to it obviously it cannot work, since EsGRID it's at the same level of tBOX, accordingly to the image where you are using the full qualified paths.
You have to go up one dir to exit from tBOX and enter EsGRID.
You can also see it from the messagebox with the error.

Apply the same logic to the other paths.

Ok that worked.

Although I still think this is really messed up. I shouldn't have to modify the include paths of user distributed "libraries" in such a way, no ?

IMHO the include path should be called from the location of the file it is used in. Would be soooo much easier

Zach wrote:Ok that worked.

Oh please stop, don't mention it.

Zach wrote: I shouldn't have to modify the include paths of user distributed "libraries" in such a way, no ?

The way to write include files working in all conditions is available, people just need to use it, but they need to know about it first.

Hopefully after painfully discovering how PB does it by default, they'll look in the forum.

At the very least there should be some kind of clear note/example in the documentation.

Oh well, thanks for helping me solve this issue.. Hopefully I won't forget

but I still hope Fred changes it to better reflect the path of the file the command is called from...

You are welcome, but IMHO don't hold your breath for this to change

> the include path should be called from the location of the file it is used in

It does. IncludeFile looks in the same folder as the source as first priority.
Then, you can choose to redirect it with "..\" and such, or IncludePath.

Zach wrote:No. It's a strange habit I picked up from somewhere, probably another programming language and I tend to use it as it looks aesthetically pleasing to me. Its just an include statement. And they don't seem to influence it or cause bugs in any way, as I've tested it by removing all of them.

This must be some sort of IDE/compiler bug with path parsing.... or a VERY poor design choice

It is most likely neither a bug nor a poor design choice. Many languages have the final definition of a Factor to include any number of variable constructs or constant constructs, OR a pair of parens surrounding a valid Expression...which trickles down to allowing a Factor.

You can tell when a language is designed that way by adding parens around a simple assignment, such as x = (5).

PB wrote:> the include path should be called from the location of the file it is used in

It does. IncludeFile looks in the same folder as the source as first priority.

Or you have misunderstood what Zack was saying, or you don't have understood the contents of this thread, or you are wrong, or all of the above at the same time, or you are using another PureBasic

And that's explain why some people will continue to use includepath and we will continue to have this problem emerging from time to time when one start to use includes beyond the trivial way (just one main source simply including its children).

luis wrote:

Zach wrote:Ok that worked.

Oh please stop, don't mention it.

@Luis: What I quoted is correct and works for me. Specifically: I can IncludeFile
another file in the same directory as the source being compiled, or another file
up one parent folder up if I put "..\" at the start of that file's path. Like this:
Is that not what we're discussing? This code compiles perfectly here, and is in
total agreement of Zach's comment of: "the include path should be called from
the location of the file it is used in."

It can probably changed to be source relative, yes.