On Wed, Sep 19, 2018 at 1:45 PM Jon Chesterfield <
jonathanchesterfield_at_[hidden]> wrote:

> Compilers use the same command line option to indicate different things.
>
> - A new revision learns to detect new errors and rolls this into an
> existing flag
> - A new revision removes a detection that proved unpopular
> - Different compiler implementations make different analyses reasonable
> - Different compiler developer motivations lead to different analyses
> - Names are hard and get reused
>
> I can see two paths for standardising the parameters passed to the
> compiler:
>
> - standardised name, implementation defined semantics
> - standardised name, standardised semantics
>
> The former appears to be worthless. I'll still need to use different flags
> with different compilers.
>

Agreed. That's not a direction worth pursuing.

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

Disagree. It'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.


> The conditional logic in build scripts to change flags based on the
> compiler is already trivial.
>

Some are trivial, some are not, and some are straightforward. As a simple
example here's the b2 code to deal with just turning threading support
on/off:

===
{
    # Handle threading
    local rule threading-flags ( * )
    {
        compile-link-flags <threading>multi/$(1) : $(2) ;
        if $(3)
        {
            toolset.flags gcc.link FINDLIBS-SA <threading>multi/$(1) : $(3)
;
        }
    }

    threading-flags <target-os>windows : -mthreads ;
    threading-flags <target-os>cygwin : -mthreads ;
    threading-flags <target-os>solaris : -pthreads : rt ;

    local bsd = [ MATCH ^(.*bsd)$ : $(all-os) ] ;
    threading-flags <target-os>$(bsd) : -pthread ;

    local no-threading = android beos haiku sgi darwin vxworks ;
    local threading-generic-os = [ set.difference $(all-os) :
$(no-threading) $(bsd) windows cygwin solaris ] ;
    threading-flags <target-os>$(threading-generic-os) : -pthread : rt ;
}
===


> Working out which flags to use is project dependent and comprises all of
> the work involved in specifying parameters.
>

I don'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?

The C++ tooling ecosystem needs improvement. I don't think this particular
> lack is a problem worth the committee time.
>

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 "options knowledge" this
would reduce it to only needing to understand one set of options.

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