<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Sep 19, 2018 at 1:45 PM Jon Chesterfield &lt;<a href="mailto:jonathanchesterfield@gmail.com" target="_blank">jonathanchesterfield@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="auto">Compilers use the same command line option to indicate different things.<div dir="auto"><br></div><div dir="auto">- A new revision learns to detect new errors and rolls this into an existing flag</div><div dir="auto">- A new revision removes a detection that proved unpopular</div><div dir="auto">- Different compiler implementations make different analyses reasonable</div><div dir="auto">- Different compiler developer motivations lead to different analyses</div><div dir="auto">- Names are hard and get reused</div><div dir="auto"><br></div><div dir="auto">I can see two paths for standardising the parameters passed to the compiler:</div><div dir="auto"><br></div><div dir="auto">- standardised name, implementation defined semantics</div><div dir="auto">- standardised name, standardised semantics</div><div dir="auto"><br></div><div dir="auto">The former appears to be worthless. I&#39;ll still need to use different flags with different compilers.</div></div></blockquote><div><br></div><div>Agreed. That&#39;s not a direction worth pursuing. </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="auto"><div dir="auto">The latter would need to convince roughly n-1 compilers to implement the same semantics as the 1, or for all to change their semantics. Regardless of how reasonable the change is given their architecture or how motivated the developers are to change from the version they already have.</div></div></blockquote><div><br></div><div>Disagree. It&#39;s about convincing N compilers to implement 1 interface using the same semantics they already have. We standardize existing behavior. But most importantly we *document* existing behavior. The current compiler landscape is the wild west of tooling where users, build systems, package manager, and so on loose.</div><div> </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="auto"><div dir="auto">The conditional logic in build scripts to change flags based on the compiler is already trivial.</div></div></blockquote><div><br></div><div>Some are trivial, some are not, and some are straightforward. As a simple example here&#39;s the b2 code to deal with just turning threading support on/off:</div><div><br></div><div>===</div><div><div>{</div><div>    # Handle threading</div><div>    local rule threading-flags ( * )</div><div>    {</div><div>        compile-link-flags &lt;threading&gt;multi/$(1) : $(2) ;</div><div>        if $(3)</div><div>        {</div><div>            toolset.flags gcc.link FINDLIBS-SA &lt;threading&gt;multi/$(1) : $(3) ;</div><div>        }</div><div>    }</div><div><br></div><div>    threading-flags &lt;target-os&gt;windows : -mthreads ;</div><div>    threading-flags &lt;target-os&gt;cygwin  : -mthreads ;</div><div>    threading-flags &lt;target-os&gt;solaris  : -pthreads : rt ;</div><div><br></div><div>    local bsd = [ MATCH ^(.*bsd)$ : $(all-os) ] ;</div><div>    threading-flags &lt;target-os&gt;$(bsd) : -pthread ;</div><div><br></div><div>    local no-threading = android beos haiku sgi darwin vxworks ;</div><div>    local threading-generic-os = [ set.difference $(all-os) : $(no-threading) $(bsd) windows cygwin solaris ] ;</div><div>    threading-flags &lt;target-os&gt;$(threading-generic-os) : -pthread : rt ;</div><div>}</div></div><div>===</div><div> </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="auto"><div dir="auto"> Working out which flags to use is project dependent and comprises all of the work involved in specifying parameters.</div></div></blockquote><div><br></div><div>I don&#39;t know what you mean by that. Are you saying that it should be up to the users to figure out the specific compiler flags they should use for each particular compiler they use and build systems, and other tools, should just use those? Or something else? Do you have examples of what you mean?</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="auto"><div dir="auto">The C++ tooling ecosystem needs improvement. I don&#39;t think this particular lack is a problem worth the committee time.</div></div></blockquote><div><br></div><div>I obviously disagree :-) I think this is helps in the key problem of simplifying the work needed for tools to understand builds. Instead of dealing with each and every tools duplicating the &quot;options knowledge&quot; this would reduce it to only needing to understand one set of options.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail-m_1725892176099530867gmail_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></div>