Nesting include files (not really a bug but...)

pdwyer · Post by **pdwyer** » Wed Jan 09, 2008 2:25 pm

I'm organising some of my code into reusable include files. I have one directory where I am puting them all. Using these in my source code is not a problem using "XIncludeFile" but when nesting them I hit this annoyance...

Lets say I have two includes. One is called "Math.pbi" and one is called "String.pbi". They sit in the same dir and the math pbi includes the string.pbi just using: XIncludeFile "string.pbi". I don't want the path list there as thats part of the point of having them all in the one directory. If I put some test code in math.pbi and run it then it's fine and finds string.pbi.

BUT. If I have a NewApp.Pb that has: XIncludeFile "F:\Programming\PureBasicCode\Includes\Math.pbi" and run it I get an error:

---------------------------
PureBasic
---------------------------
Line 5: File not found (F:\Programming\PureBasicCode\NewApp\string.pbi)
---------------------------
OK
---------------------------

Because the virtual path is virtual to the first calling code piece and not the code file that actually calls it!

I really don't want to hardcode the include full path in all the include files.

Using IncludePath doesn't help here either.

How do other people organise their includes? Specifically nested ones. "..\Folder" format only works for the top layer, not for nested includes too

Dare · Post by **Dare** » Wed Jan 09, 2008 2:52 pm

Hi mate,

Not 100% sure I am following what you're saying. However as to how I organise things - all my development apps are in "same depth" folders, ie:

Code: Select all

C:
.... apps
.... .... pb4
.... .... .... common
.... .... .... apType
.... .... .... .... appName
.... .... .... .... .... local
.... .... .... .... anotherApp
.... .... .... .... .... local
.... .... .... .... etc
.... .... .... .... .... local

so all includes are at the same level.

Within each "appName" folder the main file might have something like:

Code: Select all

XIncludeFile "local\constants.pbi"
XIncludeFile "..\..\common\someCommonCode.pb"
XIncludeFile "local\junk.pbi"

and an include in local, eg, junk.pbi, might have:

Code: Select all

XIncludeFile "local\constants.pbi"
XIncludeFile "..\..\common\someCommonCode.pbi"

Which works.

Not sure why your absolute pathing like "F:\Programming\PureBasicCode\Includes\Math.pbi" does not work. Absolute paths work here.

Yet another puzzler from the Aussie in Tokyo.

Edit:

BTW, I prefer that the main code is the reference point for includes. This makes sense to me, the include is nothing but a slave and should follow the master's bidding.

With folder structures as I use them, local includes can be copied anywhere and work.

Having a local include like the eg above suddenly looking for "C:\apps\pb4\apType\appname\local\local\constants.pbi" would mean a lot of code changes for me.

Dare · Post by **Dare** » Wed Jan 09, 2008 3:03 pm

Edited my folder structure as I depth-ed too far in the eg.

pdwyer · Post by **pdwyer** » Wed Jan 09, 2008 3:09 pm

In the example, the call to the full path math.pbi works. In the math.pbi there is a call to string.pbi but this being a nested call from one pbi in the include folder to another, doesn't use the full path to call string.

If I just run math.pbi it will find string.pbi but if I run compile an app from another dir it finds math as it has the full path but when math call string it doesn't call it in THAT local folder anymore it tries to find it back in the local directory of the app thats being compiled.

I can see why, the math PBI gets inserted into the new app.pb and then looked for but it means the local virtual path will not depend on the file calling it but on the local dir of the original source <sigh>

I'm just having a rant because I can't organise things as clean as I'd like too. PB probably won't change it as others have coped with this and it will break other code now.

poo!

pdwyer · Post by **pdwyer** » Wed Jan 09, 2008 3:10 pm

I can't use the depth technique because I usually create other depth level for an app for a new version so it will be out

Dare · Post by **Dare** » Wed Jan 09, 2008 3:19 pm

Ah, okay I see. And I sympathise. Truely.

My appnames are the versions, eg:

C:\apps\pb4\internet\appname_1.00\appname_1.10.pb
C:\apps\pb4\internet\appname_1.15\appname_1.15.pb

etc.

Could you not have all your versions at the same depth?

Code: Select all

F:
.... Programming
.... .... PureBasicCode
.... .... .... Includes
.... .... .... appName
.... .... .... .... v_1.00
.... .... .... .... v_1.25
.... .... .... .... v_etc

Not pushing this as a solution, BTW, just floating ideas.

pdwyer · Post by **pdwyer** » Wed Jan 09, 2008 3:36 pm

need t othink about it. for the moment I'll just put the full path in each include, I only have 5 (string, memory, sqlite3, network, bigint) so far so its not a biggie yet.

Been using PB long enough now to actually have enough code to need to organise

Dare · Post by **Dare** » Wed Jan 09, 2008 3:37 pm

#NULL · Post by **#NULL** » Wed Jan 09, 2008 3:55 pm

PB probably won't change it as others have coped with this and it will break other code now.

an additional XIncludeFile command wouldn't break anything (but the comprehension of beginners maybe).
anyway sometimes i wished to have a constant #PB_Compiler_FilePath which could solve that too.

ABBKlaus · Post by **ABBKlaus** » Wed Jan 09, 2008 6:32 pm

Why aren´t you using IncludePath ?

Code: Select all

IncludePath "F:\Programming\PureBasicCode\Includes"
XIncludeFile "Math.pbi"
XIncludeFile "string.pbi"

Trond · Post by **Trond** » Wed Jan 09, 2008 6:57 pm

Either you use the solution from ABBKlaus in the post above, or use this special trick to reset the include path to the path of the current file:

Code: Select all

IncludePath #PB_Compiler_File + "\.."

Every time the compiler reaches that line, the include path will be set relative to the current file, so XIncludeFile "string.pbi" will work correctly even if it is in the same directory as math.pbi, and math.pbi included with Xinclude "includes\math.pbi".

#NULL · Post by **#NULL** » Wed Jan 09, 2008 11:42 pm

ah, thank you guys

pdwyer · Post by **pdwyer** » Thu Jan 10, 2008 12:49 am

@ABBKlaus: I don't use IncludePath as the result is the same. All the include files need to have their location hardcoded. I want to avoid that if I can.

@Trond: Actually that doesn't seem to be necessary, unless you play with the IncludePath statement somewhere first the path is always set to the compiled files path and that's the whole problem.

I was hoping that the path would change to be local to the current file being passed by the compiler at that time so if Source A calls Source B in another location when source B calls source C relative paths are relative to B but they aren't they are still relative to A. This means you are limited in the way you organse the B files (re use includes) as if they inter-depend on eachother their virtual paths will be set buy a later written source file A. (ie, out of your control)

Anyway, I'll just hardcode the paths as like I said I don't have that many now so if things change in the future it's not too much work. I was just thinking about the future that's all. Kind of like having a policy that no code should use servernames only Cnames to future proof yourself from change...

"Shikataganai" as they say

Dare · Post by **Dare** » Thu Jan 10, 2008 2:00 am

I just learned a new word!

("Hey mom, listen to this .." *thwack*)

Ah well, that's just the way it is. Back to the basement and the evening meal.

pdwyer · Post by **pdwyer** » Thu Jan 10, 2008 2:36 am

You're not allowed to spell "mum" like that unless you update your location!

*thwack!*