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