[fpc-devel] "fpc -h" and "fpc -i"

[Tomas Hajny]

On 9 Nov 14, at 9:15, Dmitry Boyarintsev wrote:
> On Sun, Nov 9, 2014 at 4:27 AM, Juha Manninen <juha.manninen62 at gmail.com>
> wrote:
> 
> > 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?
> >
> 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.
> 
> 
> > 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.
> >
> 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.

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