XIncludeFile limitations or ...

Everything else that doesn't fall into one of the other PB categories.
User avatar
zekitez@lycos.com
User
User
Posts: 15
Joined: Fri Nov 11, 2005 5:42 pm
Location: Netherlands
Contact:

XIncludeFile limitations or ...

Post by zekitez@lycos.com »

I have some code split up in several files. The structure of each file looks like the example.
Each file includes all other files using "XIncludeFile" except itsself.
The code is not split in a tree-structure but split into parts that group the code together that belongs together like the code for the GUI, linked list, common procedures, globals, constants, etc.

There is one main.pb which "XIncludesFile" a.pb ... z.pb.
None of the procedures in main.pb is called from a.pb ... z.pb.
After adding some code to n.pb the compiler suddenly reports a bug because some procedure "d_n() is not a function, array, macro or linked list" but that procedure was never a problem before.
I also have problems with one file with 2 simple #constants that sometimes have to be included as "IncludeFile" and the next compile time as "XIncludeFile" before all compiles error free.

Is there some kind of limitation with XIncludeFile or is it a compiler bug or a not so obvious code bug ?

Code: Select all

========================= file main.pb

XIncludeFile a.pb
........
XIncludeFile z.pb

procedure main_1()
   b_1()
...
   k_n()
endprocedure

....

procedure main_n()
   a_1()
...
   z_n()
endprocedure


========================= file a.pb

XIncludeFile b.pb
........
XIncludeFile z.pb

procedure a_1()
   b_1()
...
   k_n()
endprocedure

....

procedure a_n()
   a_1()
...
   z_n()
endprocedure


========================= file b.pb

XIncludeFile a.pb
XIncludeFile c.pb
........
XIncludeFile z.pb

procedure b_1()
   a_1()
...
   z_2()
endprocedure

....

procedure b_n()
...
endprocedure

========================= file .....

.....

========================= file z.pb

XIncludeFile a.pb
XIncludeFile b.pb
........
XIncludeFile y.pb

procedure z_1()
   a_n()
...
   b_2()
endprocedure

....

procedure z_n()
...
endprocedure
Last edited by zekitez@lycos.com on Sat Oct 28, 2006 5:59 pm, edited 1 time in total.
Trond
Always Here
Always Here
Posts: 7446
Joined: Mon Sep 22, 2003 6:45 pm
Location: Norway

Post by Trond »

Don't xinclude a.pb if this is your main file. Since it was not included before (after all it's the main file) it will be included once at the first xinclude of it.
User avatar
zekitez@lycos.com
User
User
Posts: 15
Joined: Fri Nov 11, 2005 5:42 pm
Location: Netherlands
Contact:

Post by zekitez@lycos.com »

Trond wrote:Don't xinclude a.pb if this is your main file. Since it was not included before (after all it's the main file) it will be included once at the first xinclude of it.
:oops: My post was not complete. I have updated it.
There is one main.pb. None of the procedures in main.pb is called from a.pb ... z.pb (checked each procdure with Edit -> Find in files0.
Trond
Always Here
Always Here
Posts: 7446
Joined: Mon Sep 22, 2003 6:45 pm
Location: Norway

Post by Trond »

Not a bug.

If this is your main file:

Code: Select all

Xinclude "a.pb"
Xinclude "b.pb"
The files will end up like this:
<contents of file a>
<contents of file b>

Obvious, right?

Now, what happens if a procedure in file a calls a procedure in file b? An error because the procedure isn't declared yet.

If file a looks like this:

Code: Select all

Xinclude "b.pb"
<contents of file a>[/quote]

The files will end up like this:
<contents of file b>
<contents of file a>

This is your case. No matter how you xinclude your files, some procedures will come out in front of the other procedures, and you can't expect all procedures to be available from the first one.
User avatar
zekitez@lycos.com
User
User
Posts: 15
Joined: Fri Nov 11, 2005 5:42 pm
Location: Netherlands
Contact:

Post by zekitez@lycos.com »

Trond wrote:Not a bug.
....
No matter how you xinclude your files, some procedures will come out in front of the other procedures, and you can't expect all procedures to be available from the first one.
:oops: You are right. :lol: It is kind of chicken and egg problem (http://en.wikipedia.org/wiki/Chicken-and-egg_problem) .
I just discovered that when I make a "declare.pb" include file with only procedure declarations in it and I include that always as the second include file (after globals) in a file then there is no compiler error "d_n() is not a function, array, macro or linked list".
The file structure looks now like this:

Code: Select all

========================= file globals.pb 
structure ..
global ...

========================= file declare.pb 
XIncludeFile globals.pb
declare a_1() 
declare a_2() 
declare a_3() 
.....
declare z_n() 

========================= file main.pb 
XIncludeFile globals.pb
XIncludeFile declare.pb
XIncludeFile a.pb 
........ 
XIncludeFile z.pb 

procedure main_1() 
   b_1() 
... 
   k_n() 
endprocedure 

.... 

procedure main_n() 
   a_1() 
... 
   z_n() 
endprocedure 


========================= file a.pb 
XIncludeFile globals.pb
XIncludeFile declare.pb
XIncludeFile b.pb 
........ 
XIncludeFile z.pb 

procedure a_1() 
   b_1() 
... 
   k_n() 
endprocedure 

.... 

procedure a_n() 
   a_1() 
... 
   z_n() 
endprocedure 


========================= file b.pb 
XIncludeFile globals.pb
XIncludeFile declare.pb
XIncludeFile a.pb 
XIncludeFile c.pb 
........ 
XIncludeFile z.pb 

procedure b_1() 
   a_1() 
... 
   z_2() 
endprocedure 

.... 

procedure b_n() 
... 
endprocedure 

========================= file ..... 

..... 

========================= file z.pb 
XIncludeFile globals.pb
XIncludeFile declare.pb
XIncludeFile a.pb 
XIncludeFile b.pb 
........ 
XIncludeFile y.pb 

procedure z_1() 
   a_n() 
... 
   b_2() 
endprocedure 

.... 

procedure z_n() 
... 
endprocedure 
This solves this chicken and egg problem but also calls for a little pre-compile tool that generates the declare.pb file from the existing pb files so that the code is more or less compile sequence independent.
Hmmmm...
Post Reply