On Wed, Sep 26, 2018 at 11:29 AM JF Bastien <cxx_at_[hidden]> wrote:

> On Wed, Sep 26, 2018 at 11:14 AM Rene Rivera <grafikrobot_at_[hidden]>
> wrote:
>
>> On Wed, Sep 19, 2018 at 11:09 AM JF Bastien <cxx_at_[hidden]> wrote:
>>
>>> On Tue, Sep 18, 2018 at 7:41 PM Rene Rivera <grafikrobot_at_[hidden]>
>>> wrote:
>>>
>>>> On Tue, Sep 18, 2018 at 12:20 AM JF Bastien <cxx_at_[hidden]> wrote:
>>>>
>>>>> On Mon, Sep 17, 2018 at 3:37 PM Rene Rivera <grafikrobot_at_[hidden]>
>>>>> wrote:
>>>>>
>>>>>> On Mon, Sep 17, 2018 at 5:04 PM JF Bastien <cxx_at_[hidden]> wrote:
>>>>>>
>>>>>>> On Mon, Sep 17, 2018 at 1:38 PM Rene Rivera <grafikrobot_at_[hidden]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Mon, Sep 17, 2018 at 3:31 PM Tony V E <tvaneerd_at_[hidden]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Also, if you give me a function called std::compile(), that
>>>>>>>>> compiles code, it seems I can now write a compiler?
>>>>>>>>>
>>>>>>>>> system seems like a precedent for what you suggest, and in my
>>>>>>> experience system isn't a precedent people want us to repeat.
>>>>>>>
>>>>>>
>>>>>> "std::system" is what the sample implementation uses.. but it's
>>>>>> possible you could implement it as a direct library call (easily doable for
>>>>>> Clang, for example). And ideally production implementations would use
>>>>>> something more robust than std::system ;-)
>>>>>>
>>>>>
>>>>> What's the upside of a library call?
>>>>>
>>>>
>>>> One upside is that it's a known viable mechanism that can be
>>>> standardized.
>>>>
>>>
>>> What's the upside of this, when build systems already handle this?
>>>
>>
>> Build systems barely handle it.
>>
>
> I disagree: we manage to build code today. Works pretty well. The
> difficulty of build systems isn't mapping compiler options, it's all the
> other stuff around it.
>

I disagree... In that it works pretty well ;-) And, yes, that are other
problems with "stuff around it". But what's the point of trying to fix all
that stuff that's around when you don't fix one problem at the core?


> But it's not just build systems. It's anything that needs some
>> understanding of the options, for example code editors, binary package
>> managers, code analyzers, and so on.
>>
>
> Could your paper explain how these are helped by your proposal?
>

It could. But it will have to be limited.. As I would rather not write, as
I don't have infinite time, a novel length proposal.

Keep in mind that standardization has downsides, such as making any
>>> additions very slow, and changes nearly impossible. If I add a new option
>>> tomorrow, nobody can use it with a standards-based mechanism. Who would
>>> want to use this mechanism, given such limits?
>>>
>>
>> Yes, and I think that using a combination of the IS and SDs we can avoid
>> the downsides. I.e. we can have a "stable" set of options in the IS
>> combined with a more fluid set of options in SDs.
>>
>
> An SD is still way slower than the turnaround I have today.
>

I don't think so. An SD *could* be created / updated and approved in a day.
How often do you do compiler releases that a one day turnaround on option
changes would be a problem?


> I get the impression you're going down a rabbit hole...
>>>>>
>>>>> How is the design different from something like this:
>>>>>
>>>>> https://clang.llvm.org/docs/DriverInternals.html
>>>>>
>>>>> ?
>>>>>
>>>>
>>>> One similarity is that both compile source :-) Another, is of course,
>>>> that the clang driver (or front end) somewhat simulates the gcc front end.
>>>> That pattern is not uncommon.. I mention one of them in the prior art
>>>> section. Others are the various msvc compatible compilers, like Intel.
>>>>
>>>
>>> I'd expect not just a list of prior-art, but a comparison of what each
>>> does.
>>>
>>
>> Good idea.. I'm not going to have time to write that comparison for R0
>> though :-(
>>
>
> Understood, could you leave a "future work" item for it?
>

Sure.

Maybe the code will help explain what I have in mind:
>>>>>
>>>>>
>>>>> https://github.com/llvm-mirror/clang/blob/master/tools/driver/driver.cpp
>>>>>
>>>>>
>>>>> Or, put another way, why can't a Python script be used to frob
>>>>> command-line parameters in the way you propose?
>>>>>
>>>>
>>>> It could. Although that would be a tool and as such not something we
>>>> could put into the IS.
>>>>
>>>
>>> That raises a wider question: is SG15 constrained to putting things into
>>> the IS? Is it constrained to adopting pure C++ solutions to all problems?
>>> You seem to answer "yes" to both questions.
>>>
>>
>> No I did not answer "yes" to both. I explicitly mention using SDs as a
>> viable method also. But unless something changes in the way WG21 works I
>> don't see any other way outside out of the IS to have anything enforceable.
>>
>
> I'd like to see SG15 do things outside IS / SD.
>
> Could you answer the other question: it sounds like you absolutely want
> this in C++, not elsewhere.
>

Although I think it would be good for some use cases to have the compile
ability in C++... I would also be happy to have any *enforceable* method to
standardize the APIs between the C++ ecosystem tools outside of the IS.

As it stands, being a work in progress draft (or proposal), yes it's less
>> comprehensive than almost every other build system. But I don't think it
>> needs to be comprehensive at this point. Perhaps by the time this gets to
>> R2 it will be more comprehensive that most build systems.
>>
>
> OK, could you add this as a goal of the paper? It would have helped me
> understand where you're going with this.
>

Yes.

and the compiler vendors are in a better position to define their option
>>>> "abstraction".
>>>>
>>>
>>> Sure, all compilers have their own command-line parameters at the
>>> moment. Standardizing them seems to remove that "better position" from
>>> compiler vendors, or at a minimum impose a bunch more work on them.
>>>
>>
>> I don't think it adds much work to compiler vendors, after all they
>> already implement the option parsing. It does add work for tool vendors as
>> they will have to adjust to the new options.
>>
>
> Sure the mapping isn't hard, the extra constraints are an annoyance. What
> adds a huge burden, were we to adopt this, is that my standard library now
> *must* include a compiler. On every single desktop, laptop, and device we
> ship.
>

I don't see how that's the case. You can have a version of the library that
comes with the compiler that has the functionality. And another version
(only changing in returning an error) that doesn't have the functionality.

Why would I want your proposal over CMake?
>>>>>
>>>>
>>>> You would not choose it over CMake, or any other build system. But it
>>>> would make the build system much easier to implement.
>>>>
>>>
>>> Is that a problem worth solving compared to other tooling problems?
>>>
>>
>> Anything that makes our tools more consistent to help build understanding
>> is worth it, IMO.
>>
>
> What I'm asking is for a prioritization. Given limited time and resources,
> compared to other tooling problems, which would SG15 pick first?
>

Right.. Prioritization is important. But right now I'm the only person with
public proposals. When we have more proposals we can prioritize.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net