On Wed, Sep 19, 2018 at 1:45 PM Jon Chesterfield <jonathanchesterfield@gmail.com> 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