Lazarus has a GUI for all FPC options, parsed directly from "fpc -h" and "fpc -i".
Project Options -> Compiler Options -> Other -> All Options ...

It was temporarily broken with FPC trunk but works now. I had to hard-code some things in the parser because "fpc -h" output does not give enough data.

1. Selection lists say "see fpc -i for possible values" but there is no mention in which section exactly the values are. I think I guessed them right as nobody complained but the mapping is not always obvios. Could it be
"see fpc -i section 'ABI targets' for possible values" and
"see fpc -i section 'CPU instruction sets' for possible values" It would make the parser robust for possible future changes.

2. Some list choices can have multiple selections, for example -Oo<x>, and the GUI must use CheckBoxes.
Other list choices have one alternative selection, for example -Op<x>, and the GUI uses a ComboBox.
This difference is not indicated in "fpc -h" output anyhow. A consistent indication would make the parser more robust again.

Dmitry Boyarintsev had a plan to generate well formatted JSON with "fpc -hj" or similar.
It would be parser friendly and would contain info about which option should show in Lazarus GUI etc.
"fpc -h" output would be generated from the JSON data, thus it would not require more maintenance.
Unfortunately this will not happen anytime soon, nobody is working on it. Until then, small improvements in "fpc -h" output would be good.

One more issue are the options missing from "fpc -h". Currently I only know that -gtt, -gttt, -gtttt etc. are not mentioned, there is only -gt, yet the extra 't's are not duplicate options but they change the meaning.
Long time ago there was a discussion about those missing options but they may be added. Does anybody know?

I looked at FPC sources trying to find where the help strings are done. I only found "msgtxt.inc" which apparently is generated, but where is it generated?

Regards,
Juha

Juha Manninen wrote

Lazarus has a GUI for all FPC options, parsed directly from "fpc -h" and "fpc -i". Project Options -> Compiler Options -> Other -> All Options ...

.
.

"fpc -h" output would be generated from the JSON data, thus it would not require more maintenance.

If you mean that FPC itself should use a JSON file for generating the help, that doesn't sound like a good idea to me (see below).

I'd suggest creating a bug report about options missing in the list (mentioning -gtt[t[t]] and anything else you'd be aware of. You (or anyone else ;-) ) may deduce the list of supported options from options.pas _plus_ the options supported in fpc.pas.

This file is indeed generated from fpcsrc/compiler/msg/errore.msg where all the texts emitted by the compiler are stored while allowing easy translation to other languages (it's a simple text file with just a few conventions for proper parsing - some for the messages issued during compilation, others for proper displaying of the help).

Tomas

Tomas Hajny wrote

If you mean that FPC itself should use a JSON file for generating the help, that doesn't sound like a good idea to me (see below).

I think it is a good idea if only somebody implemented it. It is not a trivial thing to implement of course.
It seems Dmitry is not working towards a patch either so very likely this will never happen.

Anyway, the JSON records and structure would contain info about FPC targets, usefulnes in an external (Lazarus) GUI, type of selection (single/multi select), links to section lists etc., all in a parser friendly way.
A JSON parser in FPC itself would generated "fpc -h" and "fpc -i" outputs when requested, but external programs (like Lazarus) could get the JSON data with "fpc -hj" or something.
Yes, it is a good idea!

---

I have created issues
http://bugs.freepascal.org/view.php?id=27013
and
http://bugs.freepascal.org/view.php?id=27014
(as Tomas noticed.)

I don't think that it's a good idea because it would make translations more difficult than they are now and support for translations is the primary goal of the message files.

Also, all message files would need to preserve the same metadata which should be added according to your suggestion, etc. However, FPC itself couldn't use this metadata directly anyway most likely, because it needs more logic for processing these options which probably wouldn't fit in the metadata anyway. From this point of view, storing the "metadata" in a separate file is probably a better option. We could add such "metadata" file (needed for Lazarus but possibly useful to other GUIs as well) to FPC and provide means for checking the consistency with the message file (similar to the msgdiff tool), of course - but that would need to be based on some external contribution.

Indeed. :-) I've already started looking at the second one. I may have a look at the first one as well if I find enough information about meaning of the missing options easily (otherwise I'll leave it to someone else knowing more about them).

Tomas

Pardon me, but I actually opposed the idea to put any kind of changes to FPC help system.
My reasoning - it would be an additional and annoying burden to fpc-team. As bug reports showing, help is not in sync with compiler features already.

The suggestion was to have a separate machine-readable file description (that could be updated separately from the compiler), so the IDE would be up-to-date on the compiler features.
Which end up in this package: http://wiki.freepascal.org/cmdlinecfg

thanks,
Dmitry

Sorry, my bad. We had a long discussion about this subject, Mattias thought the info about FPC options should be maintained in FPC project. I agreed because it is quite logical and makes sense. Why should help info about FPC options be maintained by some other project?
Now I remember you planned this external file + a GUI in a package. I twisted your plan so that the file should be offered to FPC project.

Now it seems that my parser could became quite robust if "fpc -h" output is consistent.
It can still later be replaced by your file + GUI if it brings extra benefits.
We can discuss it later.

Juha

The problem is that this "metafile" is intent to be used by an out-side "application" not an out-side"human". FPC as an application is designed to be used by humans. If something is not "fpc -h", well humans would go out search and ask. And they'll get their answer. But why would FPC team care about something that's not in the intent of FPC itself?

And also, what about other other applications that Lazarus and FPC relies on?
Like external linkers? The number of linking options is quite-quite limited now.
And FPC provides a "-k" option to push additional parameters to the linker. Lazarus IDE could provide a nice GUI interface for linker options two, using a similar command-line parameters description file.

Yeah. That's the point I've made back at the discussion. Relying on parsing human-readable data, is not enough.
Instead of spending time improving the parser back then, you could create your description and be done.

So now, instead of waiting for the bug reports to be full filled that making and "fpc -h" more consistent, you could just update the description file for the new compiler features.

And trust me, some one will breaking "fpc -h" again and again in future. Just because, then people are adding to features to the compiler they do care about these features and they care less about consistency and nice-looking fpc help.

thanks,
Dmitry

While I agree that 'fpc -h' can never be ensured to always match the real capabilities, the same applies to the potential metadata file as well. In my view, the file for metadata makes sense especially if it contains more (or somehow different) information than what is needed and used by FPC itself.

I've finished implementation of solution for easier parsing of supported values for certain options and the solution _does_ match the compiler capabilities because the values come from the particular compiler itself. I have also improved some other aspects of the help file and will keep an eye on the remaining issues (at least those existing now ;-) ).

Tomas

Tomas Hajny wrote

I've finished implementation of solution for easier parsing of supported values for certain options and the solution _does_ match the compiler capabilities because the values come from the particular compiler itself.

Thanks. I will look at the parser next weekend.

The fact still is that "fpc -h" + a parser in Lazarus requires the least amount of maintenance in the long run.
The help output already listed the vast majority of all options. Most new options will be added there, too, even if some were forgotten. This is the same discussion we already had with Dmitry and Mattias. The external file needs maintenance for all FPC options for the eternal future.

Still, it is bad that duplicate work for the options GUI was done, considering our limited resources.
Unfortunately Dmitry proposed his system when I had already implemented the parser and GUI in Lazarus trunk and was fixing the remaining bugs.
It was discussed a couple of months before that in our mailing list. Is there any way to make a hybrid solution? The linker options indeed would bring extra value to it. But, we can discuss it in Lazarus list if needed.

Juha

OK. BTW, there's still one thing which came to my mind while looking at it
- the list of supported compilers / platforms (aka options for 'fpc -P...'). That one is not known in the platform-specific compilers but rather in the fpc helper which is the reason why I didn't add it yet. However, I'm willing to have a look at this one too if it is considered useful (let me know - e.g. by adding a note to the bug report).

OK.

Since nobody responded to the other bug report related to options missing in the list, I'll probably take it as well and ask others about the information I couldn't find in the sources myself.

Tomas

Juha Manninen wrote

The fact still is that "fpc -h" + a parser in Lazarus requires the least amount of maintenance in the long run.

The help output already listed the vast majority of all options.

Is there an exclusion for "-P" option in the parser? After all the flag make sense for "fpc" but not "ppcXXX".

thanks,
Dmitry

Yes, that option is processed by fpc normally and ignored by ppcXXX if it is called with that option. This fact may be used in makefiles so that the specific ppcXXX may be called instead of fpc under certain conditions while still allowing the same command line options to be used rather than getting an error message.

Tomas

Dmitry Boyarintsev wrote

Is there an exclusion for "-P" option in the parser? After all the flag make sense for "fpc" but not "ppcXXX".

No but IMO it should be excluded from the user choices.
The parser calls the compiler with  '-T$(TargetOS) -P$(TargetCPU)';
See function TCompilerOptReader.UpdateTargetParam: Boolean;

Juha

Ah, you meant "Lazarus parser of fpc help output" rather than "FPC command line parser".

Note that -P (in general: 'fpc' specific options) will not be listed if you call 'ppcXXX -h' rather than 'fpc -h'.

Tomas

Ah, you meant "Lazarus parser of FPC help" rather than "FPC command line parser". Note that '-P' (or any other "fpc" specific options) are not listed if calling 'ppcXXX -h' rather than 'fpc -h'.

Tomas

I have implemented support for the new "fpc -h" and "fpc -i" features in Lazarus trunk.
Works well! Please test.
Comments are welcome in Lazarus mailing list and bug reports in bug tracker.

Juha