On Thu, Nov 30, 2023 at 10:33 AM Olga Arkhipova <olgaark_at_[hidden]>
wrote:

>
>
> +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 me it feels that we should NOT standardize command line options as they
are today for two reasons:
1. What should we do if currently two vendors provide the same option in
two different ways?
2. We should leave room for vendors to interpret options as a whole, based
on the values we provide in the standard way.
I.e flags that are related to each other should be handled by the
implementation.

>
>
> 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.
>

Following the previous comment - I don't think we should standardize this
mapping or ask for it.

I may be completely wrong here and I really ask you to help me follow the
plan if so -
As I imagine it, the specific vendor's switches are like specific ASM
instructions when compiling code.
And the 'options' as described in the D3051R0 <https://wg21.link/D3051R0> are
the code that would be 'compiled' to any vendor's specific switch.
Exactly as we don't specify the ASM for compiler vendors, we should not
specify switches for vendors of tools.
We should only specify options that must be accepted, and when applicable
also their meaning.


>
> Thanks,
>
> Olga
>
>
>

Ran.


>
>
> *From:* SG15 <sg15-bounces_at_[hidden]> *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]> wrote:
>
> On Tue, Nov 28, 2023 at 5:38 AM Ran Regev <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
>
>