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.
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 the whole unit concept of object pascal has to be thrown away.
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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
