Page 1 of 1

XIncludeFile limitations or ...

Posted: Fri Oct 27, 2006 7:15 pm
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

Posted: Fri Oct 27, 2006 7:43 pm
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.

Posted: Sat Oct 28, 2006 6:02 pm
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.

Posted: Sat Oct 28, 2006 6:25 pm
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.

Posted: Sun Oct 29, 2006 8:28 am
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...