clang on macOS calls itself "Apple LLVM"

[xenu]

For reference, here's the output of a few relevant commands:

% perl -MConfig -MData::Dumper -E 'say Dumper {%Config{qw/ccname cc gccversion ccversion/}}'
$VAR1 = {
          'gccversion' => '4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.10.44.4)',
          'ccversion' => '',
          'ccname' => 'gcc',
          'cc' => 'cc'
        };

% cc --version
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

[zmughal]

Looks good to me:

# Config:{
#   'byacc' => 'byacc',
#   'cc' => 'cc',
#   'cccdlflags' => ' ',
#   'ccdlflags' => ' ',
#   'ccflags' => '-fno-common -DPERL_DARWIN -mmacosx-version-min=10.15 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -DPERL_USE_SAFE_PUTENV',
#   'ccflags_nolargefiles' => '-fno-common -DPERL_DARWIN -mmacosx-version-min=10.15 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -DPERL_USE_SAFE_PUTENV',
#   'ccflags_uselargefiles' => '',
#   'ccname' => 'gcc',
#   'ccsymbols' => '',
#   'ccversion' => '',
#   'cppccsymbols' => '',
#   'd_PRIEUldbl' => 'define',
#   'd_PRIFUldbl' => 'define',
#   'd_PRIGUldbl' => 'define',
#   'd_PRIeldbl' => 'define',
#   'd_PRIfldbl' => 'define',
#   'd_PRIgldbl' => 'define',
#   'd_SCNfldbl' => 'define',
#   'd_access' => 'define',
#   'd_accessx' => undef,
#   'd_eaccess' => undef,
#   'd_ldbl_dig' => 'define',
#   'd_locconv' => 'define',
#   'd_old_pthread_create_joinable' => undef,
#   'd_oldpthreads' => undef,
#   'd_oldsock' => undef,
#   'd_pthread_yield' => undef,
#   'd_sched_yield' => 'define',
#   'd_strtold' => 'define',
#   'd_telldir' => 'define',
#   'd_telldirproto' => 'define',
#   'gccansipedantic' => '',
#   'gccosandvers' => '',
#   'gccversion' => 'Apple LLVM 12.0.0 (clang-1200.0.32.29)',
#   'i_dld' => undef,
#   'i_sysaccess' => undef,
#   'ld' => 'cc',
#   'lddlflags' => ' -mmacosx-version-min=10.15 -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector',
#   'ldflags' => ' -mmacosx-version-min=10.15 -fstack-protector -L/usr/local/lib',
#   'ldflags_nolargefiles' => ' -mmacosx-version-min=10.15 -fstack-protector -L/usr/local/lib',
#   'ldflags_uselargefiles' => '',
#   'ldlibpthname' => 'DYLD_LIBRARY_PATH',
#   'old_pthread_create_joinable' => '',
#   'sPRIEUldbl' => '"LE"',
#   'sPRIFUldbl' => '"LF"',
#   'sPRIGUldbl' => '"LG"',
#   'sPRIeldbl' => '"Le"',
#   'sPRIfldbl' => '"Lf"',
#   'sPRIgldbl' => '"Lg"',
#   'sSCNfldbl' => '"Lf"',
#   'sched_yield' => 'sched_yield()',
#   'yacc' => 'yacc',
#   'yaccflags' => ''
# }
# Method: is_sunstudio = 0
# Method: is_msvc = undef
# Method: is_gcc = undef
# Method: is_clang = 1
# Method: compiler_command = 'clang++ -fno-common -DPERL_DARWIN -mmacosx-version-min=10.15 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -DPERL_USE_SAFE_PUTENV -xc++ -Wno-reserved-user-defined-literal'
# Method: linker_flags = '-lstdc++'
# Method: iostream_fname = 'iostream'
# Method: cpp_flavor_defs = '
# #define __INLINE_CPP_STANDARD_HEADERS 1
# #define __INLINE_CPP_NAMESPACE_STD 1
# 

via build "Perl 5.14 on macos-latest" https://github.com/zmughal/extutils-cppguess/runs/2713487247?check_suite_focus=true

[xenu]

On second thought, maybe we should differentiate between clang and Apple LLVM? It is the same compiler but it has completely different versioning scheme.

[mohawk2]

@xenu Does it need to differentiate? If not, I'm happy to merge and release this.

[zmughal]

That's what CMake does: https://cmake.org/cmake/help/latest/policy/CMP0025.html, (code search)

[zmughal]

Making them separate would help if in the future there is a compiler version check for compiler features. This is why CMake does that split -- because they need to know if the version number came from Clang or AppleClang so they can know what features are supported.

I just added a compiler feature checking method for C++ standard support, but I did not use version numbers for that (in #24).

[mohawk2]

I've rebased this against master with CI

[zmughal]

I believe that we can merge this for now as the module is not doing any compiler feature checks that depend on the version. If somebody really needs to know if they are dealing with Clang or AppleClang, it suggests there is a different problem they are trying to solve and we should just solve the different problem directly.

The version number of the compiler is not part of the API so nobody should be using that.

[mohawk2]

Thank you @xenu and @zmughal!