PureBasic Forums - English

Because PureBasic includes are relative to the main project file instead of the individual files themselves, I've had to resort to a clever solution provided by Trond:

http://www.purebasic.fr/english/viewtop ... 13&t=35288
http://www.purebasic.fr/english/viewtopic.php?t=30504

However, I have just realized that there is a cascading problem that affects #PB_Compiler_File when using this method. The actual path is never resolved for the local file in question, probably because it is assumed to be absolute (by design). This is causing the file path to get bigger and bigger as includes grow in depth until..

XIncludeFile #PB_Compiler_File+"\..\"+"lib.InterlockedCompareExchange.pb"

..

---------------------------
PureBasic
---------------------------
Line 9: File not found (\\acer\d\~\Workspaces\PureGDK\workspaces\installer\Installer.pb\..\..\..\includes\PureBasic\IsDBPLicensed\h.IsDBPLicensed.pb\..\..\CompileDBPExecutable\h.CompileDBPExecutable.pb\..\..\h.Window.pb\..\h.InterlockedCompareExchange.pb\..\lib.InterlockedCompareExchange.pb).
---------------------------
OK
---------------------------

..

Should have evaluated to: \\acer\d\~\Workspaces\PureGDK\includes\PureBasic\lib.InterlockedCompareExchange.pb

This is probably because the path length has exceeded MATH_PATH.

As a stopgap measure and to enable continued use of relative includes, "please" evaluate the full path name (such as with GetFullPathName) before assigning the value to #PB_Compiler_File!

Also of note with GetFullPathName from MSDN:

In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\\?\" to the path. For more information, see Naming a File.

Ideally, I would like to see support for relative paths that are relative to the current file. This would alleviate the problem altogether as well. But simply evaluating the full path name, I believe, should be a very simple to implement solution that would provide immediate results.

Please, consider adding this. I've had to move my project from a network path to a local path, and now to my root path to try and salvage every last character of MAX_PATH so that I can compile my project. This is extremely frustrating!

Time for a new solution, then.
Alternatively:

The problem is that "#PB_Compiler_FilePath" is not reevaluated to its absolute path for each file.

For example:
It doesn't matter how you evaluate #PB_Compiler_FilePath, with IncludePath, creative include files, or what. If you use relative paths then it just keeps getting bigger and bigger until you hit MAX_PATH.

I have over 150 .pb files in this project with many interdependencies. I work on this project across more than one computer and need all of the paths to work no matter where I'm accessing it from. Absolute includes just isn't going to cut it.

I used to access it over a network but then the path became too long. So I moved it to a local path. That also became to long. Now I've moved it to a root path just so I can get the thing to compile. Once that becomes too long I'm screwed.

I now have to copy the project folder to every computer separately just to keep it in sync where I used to be able to just access it from a network share.

I haven't read your entire post to get the complete grasp of what you are talking about but...

When I am at home and compiling I create a map to my C: drive using the folder I am developing in. Much the same way I develop on our servers at work, as in:

Home:
Z: = C:\DEV

Work:
Z: = \\SERVER\D$\DEV

I don't know if you have tried mapping a drive to your C Drive but if that does it then great! Otherwise... Ignore my post! I hate URL/UNC jibberish and the problems it creates for programmers...

And if I decide to move the project, rearrange some files, or change the drive, I may have to revise all of the paths in all files for all of my projects. That's asinine. This is an obvious oversight in the compiler.

+1
pb should definitely provide a way to do these things. i would still prefer additional 'include'-statements that work relative to current source, not having to fiddle about includepath or constants.

It seems to me too that this needs to be changed.

But if you don't use "\..\" you won't run into the problem, right?

Trond wrote:But if you don't use "\..\" you won't run into the problem, right?

It's "possible" but I would much rather concatenate the additional length of the the file and "\..\" as a stopgap than keep it as is. 255 characters is a lot more to work with when you don't have to worry about constant concatenation.

Also, the include string could be reevaluated before being "opened" to shrink the path again to its minimal length. I don't know what function is used internally but if the Unicode version of Win32 "CreateFile" were to be used it would support up to 32,767 characters instead of 255.