This is reposted because apparently it did not get recieved by the mailing list
Mailing lists / fpc-devel / 2012-01
Adding compiler directives?
4 messages · 4 people ·
- HHans-Peter Diettrich 1
- JJonas Maebe 1
- PPaul Robinson 1
- SSven Barth 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Show quoted text 10 lines
Nowadays the user has full control over his printer, its capabilities, and a bunch of tools to provide listings in various formats, fonts etc. No need for adding all that to an compiler, as opposed to batch processing on old mainframes.
A most desperately missing feature - Cross Reference generation.
Have a look at Lazarus, where you'll find tools that can do much more than the old mainframe utilities.
DoDi
This is reposted because apparently it did not get recieved by the mailing list From:…
Paul Robinson wroteI would like to ask whether there's a rule or policy on new compiler directives.
In general: the fewer, the merrier :)
The new directives are first, for printing capability:
Printing-related features is not something that we'd ordinarily put into the compiler. Source code formatting (for whatever purpose) is left to other -specialised- tools, such as
* ptop: general purpose source code formatter (included with FPC)
* Lazarus: includes various source code formatting capabilities
* maybe another tool not yet written, possibly based on other existing code
Such tools could be extended to check for specially formatted comments (such as { #PRINT ON }).
Show quoted text 10 lines
There is actually already some code for that in the compiler, although it is quite outdated and no longer used. It's in the compiler/ browcol.pas unit. It writes (wrote) out symbol browsing information that can (could) be used by the fp IDE. I don't think it included back references from places where those symbols are used inside the code though, only about where they are defined.
There's also the -vp compiler option, which writes out a file called "tree.log" that represents the parse tree (this option primarily exists to help debugging the compiler). It would not be very difficult to extend that output with adding for each loadn also the unit/line/ column information for each referenced symbol. Its format was however not designed to be easily machine-parseable, and changes from time to time as fields get added to or removed from node types in the compiler.
There's also the Lazarus IDE, which already contains code to extract all of tha information, both regarding definitions and uses (it needs it for its code navigation functionality). So maybe adding some kind of "dump" facility to that code would be better. In fact, in general simply navigating the source code in Lazarus should offer you the same information on demand as a separate cross-reference would (jump to symbol definition immediately lands you at that definition, rather than that you have to manually go looking through papers/source files for the right source file and line number based on a comment).
Jonas
Jonas Maebe wrote 17 lines
I'm always fascinated by the little gems that are in FPC and the units that come with it (even if it might not work anymore as you wrote). :)
Regards,
Sven
