llvm dev - Nov 2018 - [RFC] No longer look up bugpoint tools in PATH?

Hello all,

Earlier this week I sent up https://reviews.llvm.org/D54884, which changes
how bugpoint finds executables it relies upon to reduce programs.
Specifically:

- Before: bugpoint would only look for 'opt' in the user's PATH
- After: bugpoint looks for 'opt' in the user's PATH, and if it
doesn't
find it, looks for 'opt' in the same directory as the bugpoint
executable

I made this change because it saves me keystrokes: I always use bugpoint
from a source build, and so it's always placed in a build directory next to
opt. By searching there, I no longer need to pass it the --opt-command
option. I noticed that tools like Clang & lld behave this way as well.

On the patch Davide Italiano mentions that he's always found it strange
that bugpoint looks in the PATH at all! So I'm wondering: should I modify
my patch to change bugpoint's behavior, and no longer have it look up tools
like 'opt' in the user PATH? On the one hand, I think people like Davide
would find this more intuitive. On the other, I notice bugpoint also relies
on tools like valgrind, which are typically not placed in the same build
folder as LLVM tools, so those might be harder to look up and find.

I'm looking for people who use bugpoint regularly to respond with their own
examples and use cases, to better inform me about how bugpoint should
behave. Please let me know which PATH lookup behavior makes the most sense
to you!

Thanks!

- Brian Gesiak
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181130/f4d1712e/attachment.html>

> On the patch Davide Italiano mentions that he's always found it 
strange that bugpoint looks in the PATH at all!
Thats my impression as well!
Would be nice to remove that, saves some keystrokes (though now I do it 
subconsciously ;) ).

regards,
   Fedor.


On 11/30/18 5:27 PM, Brian Gesiak via llvm-dev wrote:
> Hello all,
>
> Earlier this week I sent up https://reviews.llvm.org/D54884, which 
> changes how bugpoint finds executables it relies upon to reduce 
> programs. Specifically:
>
> - Before: bugpoint would only look for 'opt' in the user's PATH
> - After: bugpoint looks for 'opt' in the user's PATH, and if it
> doesn't find it, looks for 'opt' in the same directory as the
bugpoint
> executable
>
> I made this change because it saves me keystrokes: I always use 
> bugpoint from a source build, and so it's always placed in a build 
> directory next to opt. By searching there, I no longer need to pass it 
> the --opt-command option. I noticed that tools like Clang & lld behave 
> this way as well.
>
> On the patch Davide Italiano mentions that he's always found it 
> strange that bugpoint looks in the PATH at all! So I'm wondering: 
> should I modify my patch to change bugpoint's behavior, and no longer 
> have it look up tools like 'opt' in the user PATH? On the one hand,
I
> think people like Davide would find this more intuitive. On the other, 
> I notice bugpoint also relies on tools like valgrind, which are 
> typically not placed in the same build folder as LLVM tools, so those 
> might be harder to look up and find.
>
> I'm looking for people who use bugpoint regularly to respond with 
> their own examples and use cases, to better inform me about how 
> bugpoint should behave. Please let me know which PATH lookup behavior 
> makes the most sense to you!
>
> Thanks!
>
> - Brian Gesiak
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 11/30/18 8:27 AM, Brian Gesiak via llvm-dev wrote:
Hello all,

Earlier this week I sent up https://reviews.llvm.org/D54884, which changes how
bugpoint finds executables it relies upon to reduce programs. Specifically:

- Before: bugpoint would only look for 'opt' in the user's PATH
- After: bugpoint looks for 'opt' in the user's PATH, and if it
doesn't find it, looks for 'opt' in the same directory as the
bugpoint executable

I made this change because it saves me keystrokes: I always use bugpoint from a
source build, and so it's always placed in a build directory next to opt. By
searching there, I no longer need to pass it the --opt-command option. I noticed
that tools like Clang & lld behave this way as well.

On the patch Davide Italiano mentions that he's always found it strange that
bugpoint looks in the PATH at all! So I'm wondering: should I modify my
patch to change bugpoint's behavior, and no longer have it look up tools
like 'opt' in the user PATH?

Yes. It has certainly been a long-term annoyance that to make bugpoint use the
opt built with bugpoint, I needed to change the PATH, or similar, when using the
corresponding opt almost always what I want to do


On the one hand, I think people like Davide would find this more intuitive. On
the other, I notice bugpoint also relies on tools like valgrind, which are
typically not placed in the same build folder as LLVM tools, so those might be
harder to look up and find.

valgrind or other "system" tools should still do a PATH lookup.
That's a different matter.

 -Hal

I'm looking for people who use bugpoint regularly to respond with their own
examples and use cases, to better inform me about how bugpoint should behave.
Please let me know which PATH lookup behavior makes the most sense to you!

Thanks!

- Brian Gesiak



_______________________________________________
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


--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181130/2a9078a6/attachment.html>

> On Nov 30, 2018, at 6:27 AM, Brian Gesiak via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hello all,
> 
> Earlier this week I sent up https://reviews.llvm.org/D54884
<https://reviews.llvm.org/D54884>, which changes how bugpoint finds
executables it relies upon to reduce programs. Specifically:
> 
> - Before: bugpoint would only look for 'opt' in the user's PATH
> - After: bugpoint looks for 'opt' in the user's PATH, and if it
doesn't find it, looks for 'opt' in the same directory as the
bugpoint executable
+1

I've never found this behavior helpful.

-- adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181130/a13b1adf/attachment.html>

On Fri, Nov 30, 2018 at 6:28 AM Brian Gesiak via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hello all,
>
> Earlier this week I sent up https://reviews.llvm.org/D54884, which changes
how bugpoint finds executables it relies upon to reduce programs. Specifically:
>
> - Before: bugpoint would only look for 'opt' in the user's PATH
> - After: bugpoint looks for 'opt' in the user's PATH, and if it
doesn't find it, looks for 'opt' in the same directory as the
bugpoint executable
>
> I made this change because it saves me keystrokes: I always use bugpoint
from a source build, and so it's always placed in a build directory next to
opt. By searching there, I no longer need to pass it the --opt-command option. I
noticed that tools like Clang & lld behave this way as well.
>
> On the patch Davide Italiano mentions that he's always found it strange
that bugpoint looks in the PATH at all! So I'm wondering: should I modify my
patch to change bugpoint's behavior, and no longer have it look up tools
like 'opt' in the user PATH? On the one hand, I think people like Davide
would find this more intuitive. On the other, I notice bugpoint also relies on
tools like valgrind, which are typically not placed in the same build folder as
LLVM tools, so those might be harder to look up and find.
>
> I'm looking for people who use bugpoint regularly to respond with their
own examples and use cases, to better inform me about how bugpoint should
behave. Please let me know which PATH lookup behavior makes the most sense to
you!
>
I guess I don't have to reiterate my point here as I originally
proposed this, so, of course +1.
You might want to wait another day or two to see if somebody is
opposed and then land the patch.

--
Davide