+1 to allow vendor specific definitions in the format.

I believe we can start only with tool specific options there. The simplest format would be just json representation on the command line switches and can be used by any tool (not just compilers).

For the common compiler options – if compilers provide a mapping from common standardized options to their specific switches (yet another json file), it can be used together with the “supported features” json to generate command line in text or json. I think this would be more flexible and easier to adopt.

Thanks,
Olga


From: SG15 <sg15-bounces_at_[hidden]ocpp.org> On Behalf Of Ran Regev via SG15
Sent: Wednesday, November 29, 2023 10:37 PM
To: René Ferdinand Rivera Morell <grafikrobot_at_[hidden]>
Cc: Ran Regev <regev.ran_at_[hidden]>; Ville Voutilainen via SG15 <sg15_at_[hidden]>; STD Proposals <std-proposals_at_[hidden]>
Subject: Re: [SG15] WIP, Tooling structured response files.


I am not sure we have to first define command line arguments and only then based on them define the file. It can easily be done the other way around: first define the file and then, if required, define the command line arguments accordingly.

I don't think we'll be ever able to define _all_ possible options for all compilers, as there are specific options for specific vendors.

Therefore, I think the way to go is to define those common options in a human readable format (aka keywords), and leave a space for vendor specific definitions.

Rene,
Can you please share with me those options that you have, I'll try to see if I can make it any sensible progress with it.


Ran.


On Tue, Nov 28, 2023, 15:18 René Ferdinand Rivera Morell <grafikrobot_at_[hidden]<mailto:grafikrobot_at_[hidden]>> wrote:
On Tue, Nov 28, 2023 at 5:38 AM Ran Regev <regev.ran_at_[hidden]<mailto:regev.ran_at_[hidden]>> wrote:
>
>> Hi Rene,
>
> Maybe I am missing something completely, but my understanding of Command Line Portability section is that it allows the user to write a response file _once_ and use it with any tool.
> My understanding is that the file and its structure is human readable and that each tool interprets it as it should.
>
> Following this logic, I would expect to see the options part specified precisely, giving tools the opportunity to implement the best they can.
> e.g, instead of this:
> { "options": [ "fPIC", { "O": "0" }, "fno-inline", { "W": [ "all", "error" ] }, "g", { "I": [ "util/include" ] }, "c" ] }
>
> I would love to see this:
> { "options": [ { "position_independent_code": true }, { "optimization": "none" }, { "allow_inline", false }, { "warnings": [ "all", "error" ] }, { "debug" : true, { "includes": [ "util/include" ] }, {"compile" : true } ] }
>
> All keys are part of the standard and are reserved words.

I would also love to see that. But, as far as I remember, the idea was
to define such new words as part of the command line arguments item.
And hence providing standard names both in the structured response
file and in command line arguments. One drawback to specifying those
option names now is that it will likely not be expansive enough by the
time we release the EcoIS. Although perhaps it can be if we can
quickly agree on common names. I already do have a large set of names
to steal from in B2 which uses tool independent features.

--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net<http://robot-dreams.net/>