<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Nov 9, 2014 at 4:27 AM, Juha Manninen <span dir="ltr"><<a href="mailto:juha.manninen62@gmail.com" target="_blank">juha.manninen62@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""></span>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?<br></blockquote><div>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?<br><br></div><div>And also, what about other other applications that Lazarus and FPC relies on?<br>Like external linkers? The number of linking options is quite-quite limited now. <br>And FPC provides a "-k" option to push additional parameters to the linker.<br></div><div>Lazarus IDE could provide a nice GUI interface for linker options two, using a similar command-line parameters description file. <br></div><div></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Now it seems that my parser could became quite robust if "fpc -h" output is consistent.</div><div>It can still later be replaced by your file + GUI if it brings extra benefits.</div><div>We can discuss it later.</div></blockquote><div>Yeah. That's the point I've made back at the discussion. Relying on parsing human-readable data, is not enough.<br></div><div>Instead of spending time improving the parser back then, you could create your description and be done.<br><br></div><div>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. <br></div><div><br>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. <br><br></div><div>thanks,<br>Dmitry<br></div></div></div></div>