[Lazarus] Parser

[Michael Schnell]

  On 07/01/2010 10:00 AM, Florian Klaempfl wrote:
> Even if FPC supported such a mess, this won't solve the fundamental
> problem with C headers: they work only properly if every used header is
> compiled for each source file again

Yep. Thats a fundamental philosophy of C. In fact there is a compiler 
flag with gcc to compile all files of a project as if there were a 
single source: simulated includes instead of linking.In fact there are C 
compilers that don't support linking at all and just compile a source 
file (with includes) directly to an executable.

Using headers is strictly optional (and of course the .h extension is 
not forced), but the _convention_ is to move commonly usable "external" 
"typedef" etc stuff into header files. There is no dedicated syntax for 
this.

(Free )Pascal, OTOH, provides syntax for doing units with an "interface" 
and provide using the "precompiled" interface definitions. Less flexible 
but more structured and faster than the C way.

> so the whole unit concept of object
> pascal has to be thrown away.
That its why a "per unit base" could be more suitable and easier to do. 
The C units would use C header files and a GNU compatible preprocessor. 
A FP-propriety interface part would be added to the C units to make them 
create an FP compatible compiled unit, usable in the normal way by 
Pascal units and by the linker.
> So using a fully automated always working
> approach you've go back to {$I ...}-style imports. Even ignoring the
> fact that the real value of a half automated translated header is that
> someone spent some brain into the translation and how it can be done in
> a pascal styled way.
Yep.

(Still considering that on top of enabling FP to compile C sources 
enabling the IDE including the debugger is an additional challenge.)
-Michael