Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Any way to to include command line options into the code?
#1
Is there any compiler directive to include command line options into the source? I've looked in the docs and in the forum, and found some mentions about "#pragma", but nothing clear.

I always include the following comment at the top of my source

Code:
' Compile with the following command:
' zxb.py myprogram.bas --tap --autorun --BASIC --strict-bool
in order to remember the options needed (sometimes I tinker with them, and they are not the same for every program). It would be easier to include the options into the source:

Code:
#option tap
#option strict-bool
or
Code:
#options tap strict-bool

Then all programs could be compiled just with zxb.py program.bas. Of course, the actual command line options would have higher priority than those in the source.
Reply
#2
The are called #pragmas (this is a standard compiler feature on most compilers). Instead of using #option, use #pragma option.

Unfortunately, YES, this is very undocumented. See how library/*.bas uses them. The reason they're undocumented is because they're being worked on and refactored at the moment.

A brief explanation follows:

To change any option use
Code:
#pragma option <optionName>=Value
For boolean options, you can use either "TRUE" | "FALSE" or 1 | 0

Example:
Disabling case-sensitive identifiers:
Code:
#pragma option case_insensitive = TRUE
Some times you might want to save current option status, to be recovered later. There is a "Stack" for this. So, to save a current option do:
Code:
#pragma push(case_insensitive)
#pragma option case_insensitive = TRUE
...
...
#pragma pop(case_insensitive)
Note: wrong push/pop sequences will lead to unpredictable results (can even crash the compiler).

The above technique is used in many library/*.bas files to make some functions case insensitive. For example, POINT and SCREEN$ functions came with Sinclair BASIC and they must be case insensitive. So saving the case_insensitive option temporarily we won't interfere with user's options status Idea

The options list grows almost day by day. But here are the most common and useful of them (at the moment), 'NAME', type, default value:
  • 'optimization', int, 0
  • 'case_insensitive', bool, False
  • 'array_base', int, 0
  • 'byref', bool, False // Whether function parameters are byRef or byVal if this is ommited
  • 'max_syntax_errors', int, DEFAULT_MAX_SYNTAX_ERRORS
  • 'string_base', int, 0
Some options (e.g. optimization) do not have effect until the parsing phase has ended. So using #pragma option with them makes no sense.
Reply
#3
Thank you. I'll try to document all this a bit in the wiki, using your message.

boriel Wrote:The options list grows almost day by day. But here are the most common and useful of them (at the moment), 'NAME', type, default value:
  • 'optimization', int, 0
  • 'case_insensitive', bool, False
  • 'array_base', int, 0
  • 'byref', bool, False // Whether function parameters are byRef or byVal if this is ommited
  • 'max_syntax_errors', int, DEFAULT_MAX_SYNTAX_ERRORS
  • 'string_base', int, 0

I blindly tried the following:

Code:
#pragma option tap = TRUE
#pragma option strict_bool = TRUE
#pragma option BASIC = TRUE
#pragma option autorun = TRUE

...just to confirm no one is yet implemented. Do you plan to implement a #pragma alternative for every command line option?
Reply
#4
Quote:
Code:
#pragma option tap = TRUE
#pragma option strict_bool = TRUE
#pragma option BASIC = TRUE
#pragma option autorun = TRUE
...just to confirm no one is yet implemented. Do you plan to implement a #pragma alternative for every command line option?
Yes, of course. Note, "tap" won't be possible, but "outputFormat" instead, which must be one of ('tap', 'tzx', 'asm', 'bin', 'ic').

Update: IC stands for "Intermediate Code". Use -e to generate it (ASCII source) and see what happens. ZXB is a *compiler toolkit* so any other high-level language that compiles into IC could be also used. I tell you this because I've noticed you're very interested in Forth. Creating a High Level Compiler that produces IC code should be not very difficult, and you could integrate Forth into the ZX Basic compiler. That is, zxf could be a main executable that later integrates the rest of the modules and libraries this toolkit uses.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)