[Lazarus] Parser

[Florian Klaempfl]

Michael Schnell schrieb:
>  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.


... and not fully automatable, so not better than current solutions.
Even worse, it does not cover the cases which are really a problem like

#define CONFIGURE_THE_HEADER_IN_A_CERTAIN_WAY // simple example are the
UNICODE define in windows headers
#include <myheader.h>

Things like this are the really nasty corner cases which make h2pas only
semi automatic.

Show me a tool which translates C headers fully automatic in *usable*
pascal units (test case e.g. glibc and mysql), then we can continue this
discussion.