[llvm-dev] PSA: debuginfo-tests workflow changing slightly
Zachary Turner via llvm-dev
llvm-dev at lists.llvm.org
Wed Dec 6 10:26:23 PST 2017
Sure, that would help. Thanks
On Wed, Dec 6, 2017 at 10:25 AM Don Hinton <hintonda at gmail.com> wrote:
> 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/abbc69bf/attachment.html>
More information about the llvm-dev
mailing list