[llvm-dev] PSA: debuginfo-tests workflow changing slightly

Don Hinton via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 6 10:25:03 PST 2017


On Wed, Dec 6, 2017 at 10:23 AM, Adrian Prantl <aprantl at apple.com> wrote:

>
>
> On Dec 6, 2017, at 10:21 AM, Zachary Turner <zturner at google.com> wrote:
>
> Can I have some assurance that if it fails again, someone will look into
> who has access to the builders so I don't have to keep doing speculative
> commits?
>
>
> Sure. I did this last time and I promise to also do it this time.
>

I'd be happy to create a new phab diff for this it that would help...


>
> -- adrian
>
>
> On Wed, Dec 6, 2017 at 10:13 AM Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>> On Dec 6, 2017, at 10:10 AM, Zachary Turner <zturner at google.com> wrote:
>>
>> Adrian, Mike, Chris?  Any update on this?  I've temporarily switched to
>> working on something different, but I plan to be back on this in a couple
>> of weeks.  It's been a month since my first revert of this CL, which seems
>> like a reasonable amount of lead-time to deal with issues surrounding
>> downstream buildbot failures.  I'm planning to move forward with this in a
>> couple of weeks once I finish up my current task, and I would really prefer
>> to not be further blocked by downstream buildbot failures.
>>
>> Is there any way you can try Don's patch above on one of the failing
>> machines?  Or proceed with your earlier solution of fixing up all the
>> jenkins builders?
>>
>>
>> When he has verified that they work locally on a Darwin machine, they
>> should also work on the bots. We don't have any special configuration on
>> those machines that isn't also visible in the Jenkins build log. I don't
>> mind you committing the patch to verify that they work as long as you keep
>> a close eye on the bots to ensure that they don't break and immediately
>> revert if they do.
>>
>> -- adrian
>>
>>
>> On Sat, Nov 25, 2017 at 3:46 PM Don Hinton <hintonda at gmail.com> wrote:
>>
>>> Hi Zachary:
>>>
>>> I was able to reproduce the greendragon results locally (OSX), and fix
>>> the problem by excluding 'debuginfo-tests' from check-clang -- this
>>> prevents them from being added twice, once for check-clang and again for
>>> check-debuginfo.
>>>
>>> Below are the minimized patches I used to reproduce and fix the problem
>>> -- based on your originals.
>>>
>>> I've verified these patches work when including debuginfo-tests in
>>> either clang/test or llvm/projects.
>>>
>>> hth...
>>> don
>>>
>>>
>>> local:/Users/dhinton/projects/llvm_project/llvm/tools/clang $ git diff
>>> master
>>> diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
>>> index c1ac9e4f0f..8c2db7600d 100644
>>> --- a/test/CMakeLists.txt
>>> +++ b/test/CMakeLists.txt
>>> @@ -131,3 +131,7 @@ add_lit_testsuites(CLANG ${CMAKE_CURRENT_SOURCE_DIR}
>>>  add_custom_target(clang-test)
>>>  add_dependencies(clang-test check-clang)
>>>  set_target_properties(clang-test PROPERTIES FOLDER "Clang tests")
>>> +
>>> +if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests/CMakeLists.
>>> txt")
>>> +  add_subdirectory(debuginfo-tests)
>>> +endif()
>>> diff --git a/test/lit.cfg.py b/test/lit.cfg.py
>>> index 39bdf36afd..5323cfe735 100644
>>> --- a/test/lit.cfg.py
>>> +++ b/test/lit.cfg.py
>>> @@ -31,7 +31,7 @@ config.suffixes = ['.c', '.cpp', '.cppm', '.m', '.mm',
>>> '.cu',
>>>  # excludes: A list of directories to exclude from the testsuite. The
>>> 'Inputs'
>>>  # subdirectories contain auxiliary inputs for various tests in their
>>> parent
>>>  # directories.
>>> -config.excludes = ['Inputs', 'CMakeLists.txt', 'README.txt',
>>> 'LICENSE.txt']
>>> +config.excludes = ['Inputs', 'CMakeLists.txt', 'README.txt',
>>> 'LICENSE.txt', 'debuginfo-tests']
>>>
>>>  # test_source_root: The root path where tests are located.
>>>  config.test_source_root = os.path.dirname(__file__)
>>> @@ -58,8 +58,6 @@ tool_dirs = [config.clang_tools_dir,
>>> config.llvm_tools_dir]
>>>
>>>  tools = [
>>>      'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 'opt',
>>> -    ToolSubst('%test_debuginfo', command=os.path.join(
>>> -        config.llvm_src_root, 'utils', 'test_debuginfo.pl')),
>>>      ToolSubst('%clang_func_map', command=FindTool(
>>>          'clang-func-mapping'), unresolved='ignore'),
>>>  ]
>>>
>>>
>>> local:/Users/dhinton/projects/llvm_project/debuginfo-tests $ git diff master
>>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>>> new file mode 100644
>>> index 0000000..87260f1
>>> --- /dev/null
>>> +++ b/CMakeLists.txt
>>> @@ -0,0 +1,26 @@
>>> +# Debug Info tests.  These tests invoke clang to generate programs with
>>> +# various types of debug info, and then run those programs under a debugger
>>> +# such as GDB or LLDB to verify the results.
>>> +
>>> +set(DEBUGINFO_TESTS_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
>>> +set(DEBUGINFO_TESTS_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
>>> +
>>> +set(DEBUGINFO_TEST_DEPS
>>> +  clang
>>> +  FileCheck
>>> +  count
>>> +  not
>>> +  )
>>> +
>>> +configure_lit_site_cfg(
>>> +  ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in
>>> +  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg.py
>>> +  MAIN_CONFIG
>>> +  ${CMAKE_CURRENT_SOURCE_DIR}/lit.cfg.py
>>> +  )
>>> +
>>> +add_lit_testsuite(check-debuginfo "Running debug info integration tests"
>>> +  ${CMAKE_CURRENT_BINARY_DIR}
>>> +  DEPENDS ${DEBUGINFO_TEST_DEPS}
>>> +  )
>>> +set_target_properties(check-debuginfo PROPERTIES FOLDER "Debug info tests")
>>> diff --git a/lit.cfg.py b/lit.cfg.py
>>> new file mode 100644
>>> index 0000000..ad65f46
>>> --- /dev/null
>>> +++ b/lit.cfg.py
>>> @@ -0,0 +1,59 @@
>>> +# -*- Python -*-
>>> +
>>> +import os
>>> +import platform
>>> +import re
>>> +import subprocess
>>> +import tempfile
>>> +
>>> +import lit.formats
>>> +import lit.util
>>> +
>>> +from lit.llvm import llvm_config
>>> +from lit.llvm.subst import ToolSubst
>>> +from lit.llvm.subst import FindTool
>>> +
>>> +# Configuration file for the 'lit' test runner.
>>> +
>>> +# name: The name of this test suite.
>>> +config.name = 'debuginfo-tests'
>>> +
>>> +# testFormat: The test format to use to interpret tests.
>>> +#
>>> +# For now we require '&&' between commands, until they get globally killed and
>>> +# the test runner updated.
>>> +config.test_format = lit.formats.ShTest(not llvm_config.use_lit_shell)
>>> +
>>> +# suffixes: A list of file extensions to treat as test files.
>>> +config.suffixes = ['.c', '.cpp', '.m']
>>> +
>>> +# excludes: A list of directories to exclude from the testsuite. The 'Inputs'
>>> +# subdirectories contain auxiliary inputs for various tests in their parent
>>> +# directories.
>>> +config.excludes = ['Inputs']
>>> +
>>> +# test_source_root: The root path where tests are located.
>>> +config.test_source_root = os.path.join(config.debuginfo_tests_src_root)
>>> +
>>> +# test_exec_root: The root path where tests should be run.
>>> +config.test_exec_root = config.debuginfo_tests_obj_root
>>> +
>>> +llvm_config.use_default_substitutions()
>>> +
>>> +llvm_config.use_clang()
>>> +
>>> +if config.llvm_use_sanitizer:
>>> +    # Propagate path to symbolizer for ASan/MSan.
>>> +    llvm_config.with_system_environment(
>>> +        ['ASAN_SYMBOLIZER_PATH', 'MSAN_SYMBOLIZER_PATH'])
>>> +
>>> +tool_dirs = [config.llvm_tools_dir]
>>> +
>>> +tools = [
>>> +    ToolSubst('%test_debuginfo', command=os.path.join(
>>> +        config.debuginfo_tests_src_root, 'test_debuginfo.pl')),
>>> +]
>>> +
>>> +llvm_config.add_tool_substitutions(tools, tool_dirs)
>>> +
>>> +lit.util.usePlatformSdkOnDarwin(config, lit_config)
>>> diff --git a/lit.site.cfg.py.in b/lit.site.cfg.py.in
>>> new file mode 100644
>>> index 0000000..8c4481a
>>> --- /dev/null
>>> +++ b/lit.site.cfg.py.in
>>> @@ -0,0 +1,25 @@
>>> + at LIT_SITE_CFG_IN_HEADER@
>>> +
>>> +import lit.util
>>> +
>>> +config.test_exec_root = "@CMAKE_BINARY_DIR@"
>>> +
>>> +config.llvm_src_root = "@LLVM_SOURCE_DIR@"
>>> +config.llvm_obj_root = "@LLVM_BINARY_DIR@"
>>> +config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
>>> +config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
>>> +config.llvm_shlib_dir = "@SHLIBDIR@"
>>> +config.llvm_plugin_ext = "@LLVM_PLUGIN_EXT@"
>>> +config.debuginfo_tests_obj_root = "@DEBUGINFO_TESTS_BINARY_DIR@"
>>> +config.debuginfo_tests_src_root = "@DEBUGINFO_TESTS_SOURCE_DIR@"
>>> +config.has_lld = lit.util.pythonize_bool("@DEBUGINFO_TESTS_HAS_LLD@")
>>> +config.host_triple = "@LLVM_HOST_TRIPLE@"
>>> +config.target_triple = "@TARGET_TRIPLE@"
>>> +config.host_arch = "@HOST_ARCH@"
>>> +
>>> +config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
>>> +
>>> + at LIT_SITE_CFG_IN_FOOTER@
>>> +
>>> +# Let the main config do the real work.
>>> +lit_config.load_config(config, "@DEBUGINFO_TESTS_SOURCE_DIR@/lit.cfg.py")
>>> diff --git a/test_debuginfo.pl b/test_debuginfo.pl
>>> new file mode 100755
>>> index 0000000..adc11c3
>>> --- /dev/null
>>> +++ b/test_debuginfo.pl
>>> @@ -0,0 +1,80 @@
>>> +#!/usr/bin/perl
>>> +#
>>> +# This script tests debugging information generated by a compiler.
>>> +# Input arguments
>>> +#   - Input source program. Usually this source file is decorated using
>>> +#     special comments to communicate debugger commands.
>>> +#   - Executable file. This file is generated by the compiler.
>>> +#
>>> +# This perl script extracts debugger commands from input source program
>>> +# comments in a script. A debugger is used to load the executable file
>>> +# and run the script generated from source program comments. Finally,
>>> +# the debugger output is checked, using FileCheck, to validate
>>> +# debugging information.
>>> +#
>>> +# On Darwin the default is to use the llgdb.py wrapper script which
>>> +# translates gdb commands into their lldb equivalents.
>>> +
>>> +use File::Basename;
>>> +use Config;
>>> +use Cwd;
>>> +
>>> +my $testcase_file = $ARGV[0];
>>> +my $executable_file = $ARGV[1];
>>> +
>>> +my $input_filename = basename $testcase_file;
>>> +my $output_dir = dirname $executable_file;
>>> +
>>> +my $debugger_script_file = "$output_dir/$input_filename.debugger.script";
>>> +my $output_file = "$output_dir/$input_filename.gdb.output";
>>> +
>>> +my %cmd_map = ();
>>> +# Assume lldb to be the debugger on Darwin.
>>> +my $use_lldb = 0;
>>> +$use_lldb = 1 if ($Config{osname} eq "darwin");
>>> +
>>> +# Extract debugger commands from testcase. They are marked with DEBUGGER:
>>> +# at the beginning of a comment line.
>>> +open(INPUT, $testcase_file);
>>> +open(OUTPUT, ">$debugger_script_file");
>>> +while(<INPUT>) {
>>> +    my($line) = $_;
>>> +    $i = index($line, "DEBUGGER:");
>>> +    if ( $i >= 0) {
>>> +        $l = length("DEBUGGER:");
>>> +        $s = substr($line, $i + $l);
>>> +        print OUTPUT  "$s";
>>> +    }
>>> +}
>>> +print OUTPUT "\n";
>>> +print OUTPUT "quit\n";
>>> +close(INPUT);
>>> +close(OUTPUT);
>>> +
>>> +# setup debugger and debugger options to run a script.
>>> +my $my_debugger = $ENV{'DEBUGGER'};
>>> +if (!$my_debugger) {
>>> +    if ($use_lldb) {
>>> +        my $path = dirname(Cwd::abs_path($0));
>>> +        $my_debugger = "/usr/bin/env python $path/llgdb.py";
>>> +    } else {
>>> +        $my_debugger = "gdb";
>>> +    }
>>> +}
>>> +
>>> +# quiet / exit after cmdline / no init file / execute script
>>> +my $debugger_options = "-q -batch -n -x";
>>> +
>>> +# run debugger and capture output.
>>> +system("$my_debugger $debugger_options $debugger_script_file $executable_file > $output_file 2>&1");
>>> +
>>> +# validate output.
>>> +system("FileCheck", "-input-file", "$output_file", "$testcase_file");
>>> +if ($?>>8 == 1) {
>>> +    print "Debugger output was:\n";
>>> +    system("cat", "$output_file");
>>> +    exit 1;
>>> +}
>>> +else {
>>> +    exit 0;
>>> +}
>>>
>>>
>>> local:/Users/dhinton/projects/llvm_project/llvm $ git diff master
>>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>>> index 8cd9d053c63..7d0fe05b511 100644
>>> --- a/CMakeLists.txt
>>> +++ b/CMakeLists.txt
>>> @@ -110,7 +110,7 @@ endif()
>>>  # LLVM_EXTERNAL_${project}_SOURCE_DIR using LLVM_ALL_PROJECTS
>>>  # This allows an easy way of setting up a build directory for llvm and another
>>>  # one for llvm+clang+... using the same sources.
>>> -set(LLVM_ALL_PROJECTS "clang;libcxx;libcxxabi;lldb;compiler-rt;lld;polly")
>>> +set(LLVM_ALL_PROJECTS "clang;libcxx;libcxxabi;lldb;compiler-rt;lld;polly,debuginfo-tests")
>>>  set(LLVM_ENABLE_PROJECTS "" CACHE STRING
>>>  	"Semicolon-separated list of projects to build (${LLVM_ALL_PROJECTS}), or \"all\".")
>>>  if( LLVM_ENABLE_PROJECTS STREQUAL "all" )
>>> @@ -885,13 +885,16 @@ if( LLVM_INCLUDE_EXAMPLES )
>>>  endif()
>>>
>>>  if( LLVM_INCLUDE_TESTS )
>>> -  if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite AND TARGET clang)
>>> -    include(LLVMExternalProjectUtils)
>>> -    llvm_ExternalProject_Add(test-suite ${LLVM_MAIN_SRC_DIR}/projects/test-suite
>>> -      USE_TOOLCHAIN
>>> -      EXCLUDE_FROM_ALL
>>> -      NO_INSTALL
>>> -      ALWAYS_CLEAN)
>>> +  if(TARGET clang)
>>> +    if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite)
>>> +      include(LLVMExternalProjectUtils)
>>> +      llvm_ExternalProject_Add(test-suite ${LLVM_MAIN_SRC_DIR}/projects/test-suite
>>> +        USE_TOOLCHAIN
>>> +        EXCLUDE_FROM_ALL
>>> +        NO_INSTALL
>>> +        ALWAYS_CLEAN)
>>> +    endif()
>>> +    add_llvm_external_project(debuginfo-tests projects/debuginfo-tests)
>>>    endif()
>>>    add_subdirectory(utils/lit)
>>>    add_subdirectory(test)
>>> diff --git a/projects/CMakeLists.txt b/projects/CMakeLists.txt
>>> index 9102efbdcb4..11835fa89d2 100644
>>> --- a/projects/CMakeLists.txt
>>> +++ b/projects/CMakeLists.txt
>>> @@ -10,6 +10,7 @@ foreach(entry ${entries})
>>>         (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
>>>         (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
>>>         (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/test-suite) AND
>>> +       (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests) AND
>>>         (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/parallel-libs) AND
>>>         (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/openmp))
>>>        add_subdirectory(${entry})
>>> diff --git a/utils/lit/lit/llvm/config.py b/utils/lit/lit/llvm/config.py
>>> index c631f8b8865..c2e5c9ff141 100644
>>> --- a/utils/lit/lit/llvm/config.py
>>> +++ b/utils/lit/lit/llvm/config.py
>>> @@ -413,8 +413,10 @@ class LLVMConfig(object):
>>>              self.config.substitutions.append(
>>>                  ('%target_itanium_abi_host_triple', ''))
>>>
>>> -        self.config.substitutions.append(
>>> -            ('%src_include_dir', self.config.clang_src_dir + '/include'))
>>> +        clang_src_dir = getattr(self.config, 'clang_src_dir', None)
>>> +        if clang_src_dir:
>>> +            self.config.substitutions.append(
>>> +                ('%src_include_dir', os.path.join(clang_src_dir, 'include')))
>>>
>>>          # FIXME: Find nicer way to prohibit this.
>>>          self.config.substitutions.append(
>>> diff --git a/utils/test_debuginfo.pl b/utils/test_debuginfo.pl
>>> deleted file mode 100755
>>> index aaf90d95468..00000000000
>>> --- a/utils/test_debuginfo.pl
>>> +++ /dev/null
>>> @@ -1,80 +0,0 @@
>>> -#!/usr/bin/perl
>>> -#
>>> -# This script tests debugging information generated by a compiler.
>>> -# Input arguments
>>> -#   - Input source program. Usually this source file is decorated using
>>> -#     special comments to communicate debugger commands.
>>> -#   - Executable file. This file is generated by the compiler.
>>> -#
>>> -# This perl script extracts debugger commands from input source program
>>> -# comments in a script. A debugger is used to load the executable file
>>> -# and run the script generated from source program comments. Finally,
>>> -# the debugger output is checked, using FileCheck, to validate
>>> -# debugging information.
>>> -#
>>> -# On Darwin the default is to use the llgdb.py wrapper script which
>>> -# translates gdb commands into their lldb equivalents.
>>> -
>>> -use File::Basename;
>>> -use Config;
>>> -use Cwd;
>>> -
>>> -my $testcase_file = $ARGV[0];
>>> -my $executable_file = $ARGV[1];
>>> -
>>> -my $input_filename = basename $testcase_file;
>>> -my $output_dir = dirname $executable_file;
>>> -
>>> -my $debugger_script_file = "$output_dir/$input_filename.debugger.script";
>>> -my $output_file = "$output_dir/$input_filename.gdb.output";
>>> -
>>> -my %cmd_map = ();
>>> -# Assume lldb to be the debugger on Darwin.
>>> -my $use_lldb = 0;
>>> -$use_lldb = 1 if ($Config{osname} eq "darwin");
>>> -
>>> -# Extract debugger commands from testcase. They are marked with DEBUGGER:
>>> -# at the beginning of a comment line.
>>> -open(INPUT, $testcase_file);
>>> -open(OUTPUT, ">$debugger_script_file");
>>> -while(<INPUT>) {
>>> -    my($line) = $_;
>>> -    $i = index($line, "DEBUGGER:");
>>> -    if ( $i >= 0) {
>>> -        $l = length("DEBUGGER:");
>>> -        $s = substr($line, $i + $l);
>>> -        print OUTPUT  "$s";
>>> -    }
>>> -}
>>> -print OUTPUT "\n";
>>> -print OUTPUT "quit\n";
>>> -close(INPUT);
>>> -close(OUTPUT);
>>> -
>>> -# setup debugger and debugger options to run a script.
>>> -my $my_debugger = $ENV{'DEBUGGER'};
>>> -if (!$my_debugger) {
>>> -    if ($use_lldb) {
>>> -        my $path = dirname(Cwd::abs_path($0));
>>> -        $my_debugger = "/usr/bin/env python $path/../tools/clang/test/debuginfo-tests/llgdb.py";
>>> -    } else {
>>> -        $my_debugger = "gdb";
>>> -    }
>>> -}
>>> -
>>> -# quiet / exit after cmdline / no init file / execute script
>>> -my $debugger_options = "-q -batch -n -x";
>>> -
>>> -# run debugger and capture output.
>>> -system("$my_debugger $debugger_options $debugger_script_file $executable_file > $output_file 2>&1");
>>> -
>>> -# validate output.
>>> -system("FileCheck", "-input-file", "$output_file", "$testcase_file");
>>> -if ($?>>8 == 1) {
>>> -    print "Debugger output was:\n";
>>> -    system("cat", "$output_file");
>>> -    exit 1;
>>> -}
>>> -else {
>>> -    exit 0;
>>> -}
>>>
>>>
>>>
>>> On Tue, Nov 21, 2017 at 9:29 PM, Zachary Turner <zturner at google.com>
>>> wrote:
>>>
>>>> Definitely welcome to look into it, but unless you have physical access
>>>> to one of these buildbots, I don't think we should commit anything else
>>>> speculatively without having someone who does have physical access first
>>>> confirm it.
>>>>
>>>> On Tue, Nov 21, 2017 at 7:25 PM Don Hinton <hintonda at gmail.com> wrote:
>>>>
>>>>> I sorta enjoy debugging stuff like this, so if you don't mind, I'll
>>>>> dig into it once I get a chance -- traveling so, my access is a bit sketchy
>>>>> right now.
>>>>>
>>>>> I'll see if I can grab the logs and let you know if I find anything
>>>>> interesting.
>>>>>
>>>>> On Tue, Nov 21, 2017 at 7:04 PM, Zachary Turner <zturner at google.com>
>>>>> wrote:
>>>>>
>>>>>> That change was added specifically to workaround a failure in a
>>>>>> previous version of the commit.  I think as chandler says it's pretty much
>>>>>> impossible for me to make any progress unless someone whose build bot is
>>>>>> failing actually sits down, applies the patch, makes it work, and then
>>>>>> sends me back the result.
>>>>>>
>>>>>> On Tue, Nov 21, 2017 at 7:03 PM Don Hinton <hintonda at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Zackary,
>>>>>>>
>>>>>>> Did you see my followup to you cfe-commits rollback:
>>>>>>>
>>>>>>>   http://lists.llvm.org/pipermail/cfe-commits/Week-of-
>>>>>>> Mon-20171120/210212.html
>>>>>>>
>>>>>>> I think you can just remove the change to cfe/trunk/test/CMakeLists.txt
>>>>>>> and it should work just fine.
>>>>>>>
>>>>>>> hth...
>>>>>>> don
>>>>>>>
>>>>>>> On Tue, Nov 21, 2017 at 12:00 PM Zachary Turner via llvm-dev <
>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>
>>>>>>>> Just an update,
>>>>>>>>
>>>>>>>> At this point I've submitted and reverted this probably 6+ times,
>>>>>>>> and I don't have time to be blocked by this anymore.
>>>>>>>>
>>>>>>>> I'm looking into alternatives for now, including ways of creating a
>>>>>>>> new top-level git repo such as https://git.llvm.org/git/
>>>>>>>> codeview-tests.git/.
>>>>>>>>
>>>>>>>> I wish there were another way, but at this point I've been working
>>>>>>>> on appeasing this for close to 2 months and I need some control over the
>>>>>>>> bits that determine whether I'm able to make forward progress.
>>>>>>>>
>>>>>>>> If and when someone on the Apple side has some time to make this
>>>>>>>> work with their build infrastructure, I will be happy to revisit.
>>>>>>>>
>>>>>>>> On Mon, Nov 13, 2017 at 4:44 PM Zachary Turner <zturner at google.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Great!  It's close to the end of the day, so I'll submit tomorrow
>>>>>>>>> to make sure everything has a chance to go fully green again to ensure I
>>>>>>>>> get failure emails if it breaks.
>>>>>>>>>
>>>>>>>>> On Mon, Nov 13, 2017 at 4:43 PM Adrian Prantl <aprantl at apple.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I can confirm that that fixes the issue!
>>>>>>>>>>
>>>>>>>>>> — adrian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Nov 13, 2017, at 4:38 PM, Zachary Turner <zturner at google.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Yea I also just found it.  Try adding this code in the bottom of
>>>>>>>>>> debuginfo-tests/lit.cfg.py
>>>>>>>>>>
>>>>>>>>>> lit.util.usePlatformSdkOnDarwin(config, lit_config)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Ha! Found it. *Somebody* is setting an SDKROOT variable in the
>>>>>>>>>>> environment. Can you find the code that would do this?
>>>>>>>>>>>
>>>>>>>>>>> — adrian
>>>>>>>>>>>
>>>>>>>>>>> > On Nov 13, 2017, at 4:30 PM, Adrian Prantl via llvm-dev <
>>>>>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> > Yes I can reproduce this locally. It looks like we are not
>>>>>>>>>>> passing an -isysroot (pointing to the SDK) to clang but it isn’t clear what
>>>>>>>>>>> lit magic would expand this.
>>>>>>>>>>> >
>>>>>>>>>>> > -- adrian
>>>>>>>>>>> >
>>>>>>>>>>> >> On Nov 13, 2017, at 3:30 PM, Zachary Turner <
>>>>>>>>>>> zturner at google.com> wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> Yea I'm preparing a revert right now.  Does it happen for you
>>>>>>>>>>> when you run debuginfo-tests locally?
>>>>>>>>>>> >>
>>>>>>>>>>> >> On Mon, Nov 13, 2017 at 3:28 PM Adrian Prantl <
>>>>>>>>>>> aprantl at apple.com> wrote:
>>>>>>>>>>> >> Since this is causing all of our internal CI to back up,
>>>>>>>>>>> could you please revert your two changes, so we can make sure that they
>>>>>>>>>>> were actually responsible, and can work on a fix for this? Let me know how
>>>>>>>>>>> we can help investigate this.
>>>>>>>>>>> >>
>>>>>>>>>>> >> -- adrian
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >>> On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <
>>>>>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> The first build where a test fails with similar symptoms has
>>>>>>>>>>> just one blamelist entry:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> http://green.lab.llvm.org/green/job/clang-stage1-
>>>>>>>>>>> configure-RA/40391/
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>     • Update test_debuginfo.pl script to point to new tree
>>>>>>>>>>> location. (detail/ViewSVN)
>>>>>>>>>>> >>> by zturner
>>>>>>>>>>> >>> -- adrian
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>> On Nov 13, 2017, at 3:21 PM, Zachary Turner <
>>>>>>>>>>> zturner at google.com> wrote:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> On the other hand this file hasn't changed recently, but I
>>>>>>>>>>> have no way to test this as it uses the LLDB code path, which only runs on
>>>>>>>>>>> OSX.
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <
>>>>>>>>>>> zturner at google.com> wrote:
>>>>>>>>>>> >>>> I might be missing something, but this doesn't look like me?
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> http://green.lab.llvm.org/green/job/clang-stage1-
>>>>>>>>>>> configure-RA/40478/consoleFull#-42777206a1ca8a51-
>>>>>>>>>>> 895e-46c6-af87-ce24fa4cd561
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: dbg-arg.c (34886 of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: ctor.cpp (34887 of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: ctor.cpp (34888 of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: aggregate-indirect-arg.cpp (34889
>>>>>>>>>>> of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: aggregate-indirect-arg.cpp (34890
>>>>>>>>>>> of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: dbg-arg.c (34891 of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: asan.c (34892 of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: asan.c (34893 of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: asan-blocks.c (34894 of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: asan-blocks.c (34895 of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: nested-struct.cpp (34896 of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: nested-struct.cpp (34897 of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: forward-declare-class.cpp (34898
>>>>>>>>>>> of 40729)
>>>>>>>>>>> >>>> PASS: debuginfo-tests :: forward-declare-class.cpp (34899
>>>>>>>>>>> of 40729)
>>>>>>>>>>> >>>> FAIL: debuginfo-tests :: foreach.m (34900 of 40729)
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> ******************** TEST 'debuginfo-tests :: foreach.m'
>>>>>>>>>>> FAILED ********************
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Script:
>>>>>>>>>>> >>>> --
>>>>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/bin/clang --target=x86_64-apple-darwin15.6.0
>>>>>>>>>>> -O0 -g /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m
>>>>>>>>>>> -c -o /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-
>>>>>>>>>>> tests/Output/foreach.m.tmp.o
>>>>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/bin/clang --target=x86_64-apple-darwin15.6.0
>>>>>>>>>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o
>>>>>>>>>>> -o /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.out
>>>>>>>>>>> -framework Foundation
>>>>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/llvm/utils/
>>>>>>>>>>> >>>> test_debuginfo.pl
>>>>>>>>>>> >>>>  /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m
>>>>>>>>>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-
>>>>>>>>>>> tests/Output/foreach.m.tmp.out
>>>>>>>>>>> >>>> --
>>>>>>>>>>> >>>> Exit Code: 1
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Command Output (stdout):
>>>>>>>>>>> >>>> --
>>>>>>>>>>> >>>> Debugger output was:
>>>>>>>>>>> >>>> imported lldb from: "/Applications/Xcode.app/
>>>>>>>>>>> Contents/SharedFrameworks/LLDB.framework/Versions/A/
>>>>>>>>>>> Resources/Python"
>>>>>>>>>>> >>>> error: foreach.m.tmp.out debug map object file
>>>>>>>>>>> '/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o'
>>>>>>>>>>> has changed (actual time is 0x5a0a2528, debug map time is 0x5a0a2526) since
>>>>>>>>>>> this executable was linked, file will be ignored
>>>>>>>>>>> >>>> >  break 25
>>>>>>>>>>> >>>> SBBreakpoint: id = 1, file = '', line = 25, exact_match =
>>>>>>>>>>> 0, locations = 0
>>>>>>>>>>> >>>> >  r
>>>>>>>>>>> >>>> success
>>>>>>>>>>> >>>> >  po thing
>>>>>>>>>>> >>>>  = <could not resolve type>
>>>>>>>>>>> >>>> > quit
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> --
>>>>>>>>>>> >>>> Command Output (stderr):
>>>>>>>>>>> >>>> --
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m:11:11:
>>>>>>>>>>> error: expected string not found in input
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> // CHECK: aaa
>>>>>>>>>>> >>>>           ^
>>>>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-
>>>>>>>>>>> tests/Output/foreach.m.gdb.output:1:1: note: scanning from here
>>>>>>>>>>> >>>> imported lldb from: "/Applications/Xcode.app/
>>>>>>>>>>> Contents/SharedFrameworks/LLDB.framework/Versions/A/
>>>>>>>>>>> Resources/Python"
>>>>>>>>>>> >>>> ^
>>>>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-
>>>>>>>>>>> tests/Output/foreach.m.gdb.output:2:211: note: possible
>>>>>>>>>>> intended match here
>>>>>>>>>>> >>>> error: foreach.m.tmp.out debug map object file
>>>>>>>>>>> '/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o'
>>>>>>>>>>> has changed (actual time is 0x5a0a2528, debug map time is 0x5a0a2526) since
>>>>>>>>>>> this executable was linked, file will be ignored
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> On Mon, Nov 13, 2017 at 3:17 PM Adrian Prantl <
>>>>>>>>>>> aprantl at apple.com> wrote:
>>>>>>>>>>> >>>> It looks like the bots are still red?
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> — Adrian
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>> On Nov 10, 2017, at 3:14 PM, Zachary Turner <
>>>>>>>>>>> zturner at google.com> wrote:
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Wasn't quite fixed, but it got a lot further this time.
>>>>>>>>>>> This time there was still an issue in the test_debuginfo.pl
>>>>>>>>>>> script regarding a hardcoded path to the llgdb.py script.  I think I never
>>>>>>>>>>> encountered this locally because this codepath only happens on Darwin, and
>>>>>>>>>>> I was testing on Linux.
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> (As an aside, ugh... Perl...)
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Regardless, this should be fixed in r317949, and hopefully
>>>>>>>>>>> that's the last of the issues.  I have to run for a couple of hours, but I
>>>>>>>>>>> can check on this again in a bit.  But I strongly suspect it will be fixed
>>>>>>>>>>> now.
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> On Fri, Nov 10, 2017 at 2:51 PM Adrian Prantl <
>>>>>>>>>>> aprantl at apple.com> wrote:
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>>> On Nov 10, 2017, at 2:50 PM, Zachary Turner <
>>>>>>>>>>> zturner at google.com> wrote:
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> I checked in a fix for that already, sorry for the
>>>>>>>>>>> trouble. I’m waiting for it to cycle
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> awesome. Thanks!
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> -- adrian
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>>> On Fri, Nov 10, 2017 at 2:49 PM Adrian Prantl <
>>>>>>>>>>> aprantl at apple.com> wrote:
>>>>>>>>>>> >>>>>> It looks like this broke green dragon:
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> http://green.lab.llvm.org/green/job/clang-stage1-
>>>>>>>>>>> configure-RA/40383/console
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> llvm-lit: /Users/buildslave/jenkins/
>>>>>>>>>>> workspace/clang-stage1-configure-RA/llvm/projects/
>>>>>>>>>>> libcxx/utils/libcxx/test/config.py:173: note: Adding
>>>>>>>>>>> environment variables: {'DYLD_LIBRARY_PATH': '/Users/buildslave/jenkins/
>>>>>>>>>>> workspace/clang-stage1-configure-RA/clang-build/./lib',
>>>>>>>>>>> 'LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT':
>>>>>>>>>>> '/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/clang-build/projects/libcxx/test/
>>>>>>>>>>> filesystem/Output/dynamic_env'}
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> llvm-lit: /Users/buildslave/jenkins/
>>>>>>>>>>> workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/llvm/config.py:332:
>>>>>>>>>>> note: using clang: /Users/buildslave/jenkins/
>>>>>>>>>>> workspace/clang-stage1-configure-RA/clang-build/bin/clang
>>>>>>>>>>> >>>>>> llvm-lit: /Users/buildslave/jenkins/
>>>>>>>>>>> workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/util.py:379:
>>>>>>>>>>> note: using SDKROOT: '/Applications/Xcode.app/
>>>>>>>>>>> Contents/Developer/Platforms/MacOSX.platform/Developer/
>>>>>>>>>>> SDKs/MacOSX10.12.sdk'
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> llvm-lit: /Users/buildslave/jenkins/
>>>>>>>>>>> workspace/clang-stage1-configure-RA/llvm/utils/lit/lit/TestingConfig.py:101:
>>>>>>>>>>> fatal: unable to parse config file '/Users/buildslave/jenkins/
>>>>>>>>>>> workspace/clang-stage1-configure-RA/llvm/tools/clang/
>>>>>>>>>>> test/debuginfo-tests/lit.cfg.py', traceback: Traceback (most
>>>>>>>>>>> recent call last):
>>>>>>>>>>> >>>>>>   File "/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/llvm/utils/lit/lit/TestingConfig.py", line 88, in
>>>>>>>>>>> load_from_path
>>>>>>>>>>> >>>>>>     exec(compile(data, path, 'exec'), cfg_globals, None)
>>>>>>>>>>> >>>>>>   File "/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>>>>> configure-RA/llvm/tools/clang/test/debuginfo-tests/lit.cfg.py",
>>>>>>>>>>> line 36, in <module>
>>>>>>>>>>> >>>>>>     config.test_source_root =
>>>>>>>>>>> os.path.join(config.debuginfo_tests_src_root, 'tests')
>>>>>>>>>>> >>>>>> AttributeError: TestingConfig instance has no attribute
>>>>>>>>>>> 'debuginfo_tests_src_root'
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> FAILED: CMakeFiles/check-all
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> -- adrian
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> > On Nov 10, 2017, at 1:00 PM, Zachary Turner via
>>>>>>>>>>> llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>>>>>>>> >>>>>> >
>>>>>>>>>>> >>>>>> > This is in as of r317925.  I'm keeping an eye out for
>>>>>>>>>>> failure notifications.  I may or may not need help diagnosing if something
>>>>>>>>>>> does go wrong (although I'm keeping my fingers crossed)
>>>>>>>>>>> >>>>>> >
>>>>>>>>>>> >>>>>> > On Thu, Nov 9, 2017 at 4:05 PM Zachary Turner <
>>>>>>>>>>> zturner at google.com> wrote:
>>>>>>>>>>> >>>>>> > Since it's towards the end of the day already, I'll put
>>>>>>>>>>> this in tomorrow morning around 9 or 10, to make sure I'm around to fix
>>>>>>>>>>> anything that arises (or revert).
>>>>>>>>>>> >>>>>> >
>>>>>>>>>>> >>>>>> >
>>>>>>>>>>> >>>>>> >
>>>>>>>>>>> >>>>>> > On Thu, Nov 9, 2017 at 2:53 PM Mike Edwards <
>>>>>>>>>>> medwards at apple.com> wrote:
>>>>>>>>>>> >>>>>> > Hi Zach,
>>>>>>>>>>> >>>>>> > Thanks for doing this extra work to make this lower
>>>>>>>>>>> impact for the rest of us.  Let’s give it a try and see what happens.
>>>>>>>>>>> >>>>>> >
>>>>>>>>>>> >>>>>> > -Mike
>>>>>>>>>>> >>>>>> >
>>>>>>>>>>> >>>>>> >
>>>>>>>>>>> >>>>>> >
>>>>>>>>>>> >>>>>> >> On Nov 9, 2017, at 13:37, Zachary Turner <
>>>>>>>>>>> zturner at google.com> wrote:
>>>>>>>>>>> >>>>>> >>
>>>>>>>>>>> >>>>>> >> Hi all, I think I've addressed all the concerns here,
>>>>>>>>>>> and I believe there should be no immediate impact to the current workflow.
>>>>>>>>>>> with that said, I plan to commit this either later today or early tomorrow
>>>>>>>>>>> if there are no other concerns.
>>>>>>>>>>> >>>>>> >>
>>>>>>>>>>> >>>>>> >> On Tue, Nov 7, 2017 at 12:19 PM Zachary Turner <
>>>>>>>>>>> zturner at google.com> wrote:
>>>>>>>>>>> >>>>>> >> I tested this out, and AFAICT nothing will change.  It
>>>>>>>>>>> will continue to just work if you have it checked out under clang/tests.
>>>>>>>>>>> It's a bit hard to construct this configuration locally since it requires
>>>>>>>>>>> moving some files around, and applying half of a CL here and half of a CL
>>>>>>>>>>> there.  But, AFAICT it works.
>>>>>>>>>>> >>>>>> >>
>>>>>>>>>>> >>>>>> >> I'm happy to send you some patches if you want to try
>>>>>>>>>>> them locally and confirm.
>>>>>>>>>>> >>>>>> >>
>>>>>>>>>>> >>>>>> >> I'd like to print out a CMake warning if it detects
>>>>>>>>>>> the tree under clang/test and just mention that the workflow is
>>>>>>>>>>> deprecated.  Any objections?
>>>>>>>>>>> >>>>>> >>
>>>>>>>>>>> >>>>>> >> On Mon, Nov 6, 2017 at 1:49 PM Mike Edwards <
>>>>>>>>>>> medwards at apple.com> wrote:
>>>>>>>>>>> >>>>>> >> Thank you Zach.
>>>>>>>>>>> >>>>>> >>
>>>>>>>>>>> >>>>>> >>
>>>>>>>>>>> >>>>>> >>> On Nov 6, 2017, at 13:37, Zachary Turner <
>>>>>>>>>>> zturner at google.com> wrote:
>>>>>>>>>>> >>>>>> >>>
>>>>>>>>>>> >>>>>> >>> I’m going to spend a little time seeing if i can make
>>>>>>>>>>> the change invisible to the bots so they will continue to work as they do
>>>>>>>>>>> today.  Will report back after I’ve explored that a bit
>>>>>>>>>>> >>>>>> >>> On Mon, Nov 6, 2017 at 1:35 PM Mike Edwards <
>>>>>>>>>>> medwards at apple.com> wrote:
>>>>>>>>>>> >>>>>> >>>> I'm honestly not opposed to this idea.  It just
>>>>>>>>>>> seems a shame to do this for purely logistical reasons if most people agree
>>>>>>>>>>> that the "right" place for debuginfo-tests is outside of the clang tree.
>>>>>>>>>>> >>>>>> >>>
>>>>>>>>>>> >>>>>> >>> I totally understand what you are saying here and
>>>>>>>>>>> will just add that sometimes being part of a larger community means being
>>>>>>>>>>> willing to do things, sometimes, not exactly the “right” way, due to
>>>>>>>>>>> logistical reasons.  I am not opposed to what you would like to do, I’m
>>>>>>>>>>> just furrowing my brow at the timeframe in which to do it.
>>>>>>>>>>> >>>>>> >>>
>>>>>>>>>>> >>>>>> >>>>
>>>>>>>>>>> >>>>>> >>>> That said, I'd still like to hear from ChrisM and
>>>>>>>>>>> MikeE about why it will take so long, because on the surface it seems like
>>>>>>>>>>> a low-impact move.
>>>>>>>>>>> >>>>>> >>>
>>>>>>>>>>> >>>>>> >>> Past experience has taught me, anything I think is
>>>>>>>>>>> going to be simple and quick to fix, rarely ever turns out that way.  While
>>>>>>>>>>> there will be a significant amount of work to change the way our bots work
>>>>>>>>>>> here at Apple, the work is not impossible to accomplish.  Given the choice,
>>>>>>>>>>> I would of course prefer an approach such as Paulr has suggested.  The
>>>>>>>>>>> ability to run things in parallel for a time provides for a much lower
>>>>>>>>>>> impact change on the entire community.  I think this approach may also give
>>>>>>>>>>> us some time to decide where the debuginfo-test should fit in the new
>>>>>>>>>>> mono-repo.  It would be a bummer to do the work necessary to make this
>>>>>>>>>>> change, only to discover we would have to do it differently in the not too
>>>>>>>>>>> distant future to accommodate the new mono-repo.
>>>>>>>>>>> >>>>>> >>>
>>>>>>>>>>> >>>>>> >>>  Zach, I do not want to be a blocker here.  I just
>>>>>>>>>>> want to make sure we have explored all of the options to make sure we are
>>>>>>>>>>> not missing a lower impact approach.  I also want to make sure we are not
>>>>>>>>>>> doing something that could wait until we migrate to the mono-repo next year.
>>>>>>>>>>> >>>>>> >>>
>>>>>>>>>>> >>>>>> >>> Thanks,
>>>>>>>>>>> >>>>>> >>> Mike
>>>>>>>>>>> >>>>>> >>
>>>>>>>>>>> >>>>>> >
>>>>>>>>>>> >>>>>> > _______________________________________________
>>>>>>>>>>> >>>>>> > LLVM Developers mailing list
>>>>>>>>>>> >>>>>> > llvm-dev at lists.llvm.org
>>>>>>>>>>> >>>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> _______________________________________________
>>>>>>>>>>> >>> LLVM Developers mailing list
>>>>>>>>>>> >>> llvm-dev at lists.llvm.org
>>>>>>>>>>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>>>>>> >>
>>>>>>>>>>> >
>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>> > LLVM Developers mailing list
>>>>>>>>>>> > llvm-dev at lists.llvm.org
>>>>>>>>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>> LLVM Developers mailing list
>>>>>>>> llvm-dev at lists.llvm.org
>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>>>
>>>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171206/a4975bc5/attachment.html>


More information about the llvm-dev mailing list