Jonas Maebe schrieb:
Next I'll move ppudump into the compiler, according to Adem's
suggestion, so that the dependency show stopper goes away.
The basic issue is that the functionality ppudump happens to depend on
must not depend on the code generator. The current build system enforces
this rather strictly. Removing the check from the build system so that
you can break this separation of concerns is just wrong.
It's hard to spot the real topics, that make ppudump so problematic. But
it's easy to incorporate ppudump into the compiler, I just did it and
will provide the according patch today.
During that work it turned out that precding hacks make ppudump hard to
maintain. In detail some enumerated types are already out of sync, with
different versions in ppudump and the original units (symconst...). I've
limited the patch to remove only identical type declarations, constant
arrays and procedures, that are no more required when the original units
can be used in ppudump. Later the string arrays, describing the
ordinals, can be moved into the units defining the enums. This will
allow for better maintenance of these types, and for better error
messages or other debug output, wherever required.
Like with the preprocessor, the ppudump functionality can be invoked
with a dedicated commandline option (e.g. -P), that is handled in
Compiler.Compile() as well.
During my work I also came across a recompilation problem. Sometimes the
new ppudump unit is not recompiled after modifications, eventual syntax
errors only turned out when pp was recompiled by the new compiler and
-B. Does this ring a bell?
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
