<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Sep 18, 2018 at 7:41 PM Rene Rivera &lt;<a href="mailto:grafikrobot@gmail.com">grafikrobot@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Sep 18, 2018 at 12:20 AM JF Bastien &lt;<a href="mailto:cxx@jfbastien.com" target="_blank">cxx@jfbastien.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Sep 17, 2018 at 3:37 PM Rene Rivera &lt;<a href="mailto:grafikrobot@gmail.com" target="_blank">grafikrobot@gmail.com</a>&gt; wrote:<br></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Sep 17, 2018 at 5:04 PM JF Bastien &lt;<a href="mailto:cxx@jfbastien.com" target="_blank">cxx@jfbastien.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Sep 17, 2018 at 1:38 PM Rene Rivera &lt;<a href="mailto:grafikrobot@gmail.com" target="_blank">grafikrobot@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Sep 17, 2018 at 3:31 PM Tony V E &lt;<a href="mailto:tvaneerd@gmail.com" target="_blank">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Also, if you give me a function called std::compile(), that compiles code, it seems I can now write a compiler?</div><div><br></div><div>int main(int argc, char ** argv)</div><div>{</div><div>    return std::compile(argc, argv);</div><div>}<br></div><div><br></div><div>Wow, that was easy.</div><div>Can the paper explain what I&#39;m misunderstanding? (Or maybe it does explain, but I missed it)</div></div></blockquote><div><br></div><div>That&#39;s a correct understanding. And that&#39;s the one example I use in my implementation &lt;<a href="https://github.com/bfgroup/std_cpp/blob/master/example/std_cpp.cpp" target="_blank">https://github.com/bfgroup/std_cpp/blob/master/example/std_cpp.cpp</a>&gt;. I do try and explain the goals in the paper. In that it serves a dual purpose. But mainly it&#39;s a way to standardize the compiler options.</div></div></div></div></blockquote><div><br></div><div>Right, otherwise you&#39;d have to do:</div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div class="gmail_quote"><div><font face="monospace, monospace"><br></font></div></div></div><div><div class="gmail_quote"><div><div><font face="monospace, monospace">int main(int argc, char** argv) {</font></div></div></div></div><div><div class="gmail_quote"><div><div><font face="monospace, monospace">    std::system((std::string(&quot;clang &quot;) + argv[1]).c_str());</font></div></div></div></div><div><div class="gmail_quote"><div><div><font face="monospace, monospace">    return 0;</font></div></div></div></div><div><div class="gmail_quote"><div><div><font face="monospace, monospace">}</font></div></div></div></div></blockquote><div dir="ltr"><div class="gmail_quote"><div><br></div><div>;-)</div><div><br></div><div>More seriously, the selection of compiler options you&#39;ve chosen seem semi-random.</div></div></div></div></blockquote><div><br></div><div>First it&#39;s not random :-) It&#39;s the minimal to get basic actual compiling working and to show highlight some of the differences in link compatibility. Second, it&#39;s very incomplete. I&#39;ll keep adding options as I implement them from now until the mailing deadline (and keep implementing them afterwards for an R1 paper -- and so on). Third, I hope I can get some volunteers to help in adding options.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> It would be useful to have a survey of existing compilers and their options, and some criteria to determine which should be supported here and which shouldn&#39;t.</div></div></div></div></blockquote><div><br></div><div>Selection criteria is indeed a hard problem. What&#39;s actually needed for core? And what can be delegated to the vendor specific realm?</div></div></div></blockquote><div><br></div><div>For context, I&#39;ve added options in the past, removed some. It&#39;s not a big deal. It would be a big deal if the standard added and removed some. That&#39;s worrying.</div></div></div></div></div></blockquote><div><br></div><div>Yes, it would be worrying. It might be the case that we need another level of options defined: core options in the IS, common options in an SD, and vendor options in SDs. Having the common options in an SD would allow for the experience gathering lifetime like TSs do for library features. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>Further, what&#39;s the expectation of the result of calling this function? Can I actually execute any code? How? Can you make sure that you take into account the restrictions various platforms have, such as requiring code authentication. It goes way beyond linkers.</div></div></div></div></blockquote><div><br></div><div>The proposal doesn&#39;t, intentionally, say anything about executing code. This is one of those &quot;implementation defined&quot; areas. Just like it is currently in the standard. If it&#39;s possible to execute code in some manner, either indirectly through an std::system equivalent or directly through JIT/DLL, is left for the implementor/compiler to document.</div></div></div></blockquote><div><br></div><div>So a valid implementation always returns true, does nothing?</div></div></div></div></div></blockquote><div><br></div><div>Yes. Returning &quot;true&quot; would get coerced to &quot;1&quot;, since the function returns an in. Which would indicate the error of not being implemented. Although ideally it would also output an error message to that effect (if possible).</div></div></div></blockquote><div><br></div><div>I meant the opposite: a valid implementation can always say &quot;success&quot; and do nothing AFAICT.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><font face="monospace, monospace">system</font> seems like a precedent for what you suggest, and in my experience <font face="monospace, monospace">system</font> isn&#39;t a precedent people want us to repeat.</div></div></div></div></blockquote><div><br></div><div>&quot;std::system&quot; is what the sample implementation uses.. but it&#39;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 ;-)</div></div></div></blockquote><div><br></div><div>What&#39;s the upside of a library call?</div></div></div></div></div></blockquote><div><br></div><div>One upside is that it&#39;s a known viable mechanism that can be standardized.</div></div></div></blockquote><div><br></div><div>What&#39;s the upside of this, when build systems already handle this? 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?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I also mention the in the paper runtime code compilation to target special runtimes in the prior art (NVRTC). There&#39;s also the possibility of tighter integration with build system to optimize build performance. </div></div></div></blockquote><div><br></div><div>Do you have numbers to back up such a claim?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div dir="ltr">I get the impression you&#39;re going down a rabbit hole...<div><br></div><div>How is the design different from something like this:</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div><a href="https://clang.llvm.org/docs/DriverInternals.html" target="_blank">https://clang.llvm.org/docs/DriverInternals.html</a></div></div></blockquote><div dir="ltr"><div>?</div></div></div></div></div></div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>I&#39;d expect not just a list of prior-art, but a comparison of what each does.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div dir="ltr"><div>Maybe the code will help explain what I have in mind:</div></div></div></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div dir="ltr"><div><a href="https://github.com/llvm-mirror/clang/blob/master/tools/driver/driver.cpp" target="_blank">https://github.com/llvm-mirror/clang/blob/master/tools/driver/driver.cpp</a></div></div></div></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div dir="ltr"><br class="m_-7709386588745186033m_3447405966987868167m_6837194064915369988gmail-Apple-interchange-newline"></div></div><div> Or, put another way, why can&#39;t a Python script be used to frob command-line parameters in the way you propose?</div></div></div></div></div></blockquote><div><br></div><div>It could. Although that would be a tool and as such not something we could put into the IS.</div></div></div></blockquote><div><br></div><div>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 &quot;yes&quot; to both questions.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> Have there been such tools in the past?</div></div></div></div></div></blockquote><div><br></div><div>Sure. I mention clang-cl in the prior art section, for example. And if I understand correctly Isabella Muerte is working on something like that also. And some build systems do essentially the same job if they in any form abstract the compiler options. That doesn&#39;t remove the desirability of having a standard set of options and a library interface. In the contrary it increases the desirability as there are obviously many instances of duplicated effort that we could could help with while increases interoperation of tools and build understanding of build products. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> Have they succeeded?</div></div></div></div></div></blockquote><div><br></div><div>Some have. </div></div></div></blockquote><div><br></div><div>I&#39;d expect the paper to list these.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> What were their approaches?</div></div></div></div></div></blockquote><div><br></div><div>I think I already answered that.. in that they simulate another such tool. Which helps in interoperation of their tool with others (i.e. being able to substitute one compiler for another in an IDE or build system transparently).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>How is this different from, say, how CMake does things? It tries to abstract away some flags and it does so much more than your proposal.</div></div></div></div></div></blockquote><div><br></div><div>Not that different.. Although this would be more comprehensive</div></div></div></blockquote><div><div><br></div><div>As it stands, the draft is way less comprehensive than CMake.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>and the compiler vendors are in a better position to define their option &quot;abstraction&quot;. </div></div></div></blockquote><div><br></div><div>Sure, all compilers have their own command-line parameters at the moment. Standardizing them seems to remove that &quot;better position&quot; from compiler vendors, or at a minimum impose a bunch more work on them.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> Why would I want your proposal over CMake?</div></div></div></div></div></blockquote><div><br></div><div>You would not choose it over CMake, or any other build system. But it would make the build system much easier to implement.</div></div></div></blockquote><div><br></div><div>Is that a problem worth solving compared to other tooling problems?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>It would also make it easier to use external libraries that use other build systems.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>As I see it, the proposal is missing a bunch of context and related research. I&#39;d like to see more to understand why it&#39;s the right tool for users of C++. I&#39;m not convinced this tool needs to be usable from C++.</div></div></div></div></div></blockquote><div><br></div><div>I will add more of the research and context as my time allows. Thanks for the feedback. I hope you can also read the &quot;Package Ecosystem Plan&quot; paper that has some of that context.</div></div><div><br></div>-- <br><div dir="ltr" class="m_-7709386588745186033m_3447405966987868167gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">-- Rene Rivera<br>-- Grafik - Don&#39;t Assume Anything<br>-- Robot Dreams - <a href="http://robot-dreams.net/" target="_blank">http://robot-dreams.net</a><br><br></div></div></div></div></div>
_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div></div>