llvm dev - Nov 2017 - PSA: debuginfo-tests workflow changing slightly

> 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
<mailto: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
<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
<http://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
<http://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 <mailto: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 <mailto: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
<mailto: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
<mailto: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 <mailto: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 <mailto:medwards at apple.com>> wrote:
> >> Thank you Zach.
> >>
> >>
> >>> On Nov 6, 2017, at 13:37, Zachary Turner <zturner at
google.com <mailto: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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/20171110/789579a9/attachment.html>

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171110/134d213f/attachment.html>

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
<http://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
<mailto:aprantl at apple.com>> wrote:
> 
>> On Nov 10, 2017, at 2:50 PM, Zachary Turner <zturner at google.com
<mailto: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
<mailto: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
<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
<http://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
<http://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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:medwards at apple.com>> wrote:
>> >> Thank you Zach.
>> >>
>> >>
>> >>> On Nov 6, 2017, at 13:37, Zachary Turner <zturner at
google.com <mailto: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 <mailto: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 <mailto:llvm-dev at
lists.llvm.org>
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/20171113/407a5060/attachment.html>