<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi All,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I also made the same mistake with this mail when replying to Pete.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Again, apologies about that! I didn't mean to take the conversation</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
privately off-list, I think it should be had publicly.<br>
</div>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr">
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Hi Pete,<br>
<br>
My concern with this approach is the expectation that the original<br>
author of a patch must provide fixes for someone else's workflow,<br>
despite possibly never performing builds that way themselves. <br>
<br>
Let me put it this way: multi-config builds are a part of my<br>
development workflow, would it therefore be equally acceptable if I<br>
started reverting any patch that broke multi-config builds and expect<br>
the original developer to fix it? Is that something I should start<br>
feeling able to do now?<br>
<br>
Or to take a more extreme example: we have some people in the community<br>
that develop on MacOS. Should they start feeling able to revert every<br>
patch that breaks MacOS builds and expect the original developer (who<br>
may very well not have a Mac, they are quite expensive after all) to<br>
fix the issue?<br>
<br>
Personally I don't think this is a sustainable process. If something<br>
breaks a person's build workflow but passes all the buildbots and<br>
passes review, I believe it should be on the person whose workflow was<br>
broken to try and fix (of course, asking the original author for help<br>
is perfectly reasonable) and not the author of every patch. I don't<br>
believe any other way of working scales to a community of more than a<br>
handful of people; after all, pretty much everyone's workflow is<br>
different!<br>
<br>
Thanks<br>
David Truby<br>
<br>
On Mon, 2020-08-03 at 15:25 +0000, Peter Steinfeld wrote:<br>
> Thanks, David.<br>
> <br>
> Out-of-tree builds are critically important for my development/review<br>
> process. When they get broken, I want them to be fixed quickly.<br>
> <br>
> One way to do that is to identify and revert the patch that broke<br>
> them. Then the author of the patch creates a solution that both<br>
> implements the original intention of the patch and also does not<br>
> break out-of-tree builds. This new patch would then be reviewed by<br>
> the person who reverted the breaking patch.<br>
> <br>
> It would be great if we could prevent out-of-tree builds from<br>
> breaking. One step in that direction would be to have buildbots for<br>
> them. But I have no idea of how difficult this would be and whether<br>
> it would be worth the effort.<br>
> <br>
> Pete<br>
> <br>
> -----Original Message-----<br>
> From: David Truby <David.Truby@arm.com> <br>
> Sent: Monday, August 3, 2020 6:06 AM<br>
> To: Peter Steinfeld <psteinfeld@nvidia.com>; Steve Scalpone <<br>
> sscalpone@nvidia.com>; isuruf@gmail.com<br>
> Subject: Re: [flang-dev] Out-of-tree flang builds<br>
> <br>
> External email: Use caution opening links or attachments<br>
> <br>
> <br>
> Hi all,<br>
> <br>
> Just to clarify, I'm not in any way opposed to out-of-tree builds and<br>
> if people rely on them then obviously we should accept patches to<br>
> keep them working. What I am opposed to here is the idea that<br>
> everyone must test every patch both in and out of tree or have their<br>
> patch reverted, especially when out of tree configurations are not<br>
> being built by any buildbots.<br>
> <br>
> To take this particular case as an example, I posted a patch fixing a<br>
> build configuration that was broken previously (note: I did not<br>
> revert the patch that broke my build configuration, I simply posted a<br>
> new patch to fix it). This patch underwent a review for 2 weeks<br>
> before being approved and passed all the buildbots we have and as<br>
> such I believe did not violate the criteria for a patch to be<br>
> reverted according to the LLVM Developer Policy:<br>
> <a href="https://llvm.org/docs/DeveloperPolicy.html#quality">https://llvm.org/docs/DeveloperPolicy.html#quality</a>.<br>
> <br>
> I did however attempt to address the issue by providing pointers to<br>
> what a quick fix might look like (such a fix has now kindly been<br>
> applied by Andrzej Warzynski in <a href="https://reviews.llvm.org/D85078">https://reviews.llvm.org/D85078</a>).<br>
> However the patch was reverted rather than an attempt at a fix being<br>
> made, which I believe would have been by far the more preferable<br>
> option (such a fix could even have been committed without review<br>
> given how simple it was).<br>
> <br>
> Obviously the revert broke my build configuration again, so the<br>
> revert somewhat makes it feel that a decision was made off-list to<br>
> consider one build configuration as more important than another. I<br>
> think if we want out-of-tree builds to be considered more important<br>
> than multi- config builds then that should be a decision made by the<br>
> community not unilaterally. I also think if that decision is made<br>
> then it must be defended by buildbots; if my patch had broken a<br>
> buildbot I would have reverted it myself!<br>
> <br>
> Thanks<br>
> David Truby<br>
> <br>
> <br>
> On Fri, 2020-07-31 at 22:14 +0000, Peter Steinfeld wrote:<br>
> > I agree that having every possible build configuration working in <br>
> > every patch is difficult.<br>
> > <br>
> > With respect to your patch being reverted – This is the crux of<br>
> > the <br>
> > matter – whether out-of-tree builds are a critical feature. If<br>
> > so, <br>
> > Tim was right to revert.<br>
> > <br>
> > It’s too bad that the buildbots don’t do out-of-tree builds. In<br>
> > the <br>
> > meanwhile, you can either do one yourself, as is documented here<br>
> > -- <br>
> > <a href="https://github.com/llvm/llvm-project/tree/master/flang">https://github.com/llvm/llvm-project/tree/master/flang</a>. Or you<br>
> > can <br>
> > ask someone who does them to review your changes. I volunteer!<br>
> > <br>
> > Pete<br>
> > From: flang-dev <flang-dev-bounces@lists.llvm.org> On Behalf Of<br>
> > David <br>
> > Truby via flang-dev<br>
> > Sent: Friday, July 31, 2020 2:53 PM<br>
> > To: Steve Scalpone <sscalpone@nvidia.com>; Isuru Fernando < <br>
> > isuruf@gmail.com><br>
> > Cc: Peter Steinfeld via flang-dev <flang-dev@lists.llvm.org><br>
> > Subject: Re: [flang-dev] Out-of-tree flang builds<br>
> > <br>
> > External email: Use caution opening links or attachments<br>
> > <br>
> > Hi all,<br>
> > <br>
> > I agree with Michael here: having every possible build<br>
> > configuration <br>
> > fixed in every commit is an impossible task. I submitted the patch<br>
> > in <br>
> > question because earlier builds broke my build configuration (and<br>
> > any <br>
> > other builds with multi-config generators, e.g. msbuild), and I <br>
> > believe submitting such a patch to fix these configurations was <br>
> > reasonable, just as submitting patches to fix out-of-tree builds<br>
> > is <br>
> > reasonable.<br>
> > <br>
> > I do not believe that this patch should have been reverted, as such<br>
> > a <br>
> > revert seems to suggest that one (non-standard?) build<br>
> > configuration <br>
> > (out of tree builds) is more important than another (non-<br>
> > standard?) <br>
> > build configuration (multi-config builds). The patch in question <br>
> > didn't fail any build bots and doesn't (I believe) fall short of<br>
> > the <br>
> > LLVM Developer Guidelines guidance on quality of patches. I believe<br>
> > a <br>
> > better course of action here would have been a patch from someone<br>
> > that <br>
> > requires out-of-tree builds to work, and I submitted some<br>
> > suggestions <br>
> > on places to look to develop an easy fix.<br>
> > <br>
> > In response to out of tree builds being a critical feature that no <br>
> > patch should break: I think in general it is unreasonable to state <br>
> > that _any_ feature that is not defended by buildbots is a critical <br>
> > feature that no patch should break. This puts a really<br>
> > unreasonable <br>
> > expectation on the developer of every patch to manually test with <br>
> > every possible configuration that some people might care about,<br>
> > rather <br>
> > than using the automated structure we already have to detect <br>
> > regressions.<br>
> > <br>
> > Thanks<br>
> > David Truby<br>
> > From: flang-dev <flang-dev-bounces@lists.llvm.org> on behalf of<br>
> > Isuru <br>
> > Fernando via flang-dev <flang-dev@lists.llvm.org><br>
> > Sent: 31 July 2020 20:52<br>
> > To: Steve Scalpone <sscalpone@nvidia.com><br>
> > Cc: Peter Steinfeld via flang-dev <flang-dev@lists.llvm.org><br>
> > Subject: Re: [flang-dev] Out-of-tree flang builds<br>
> > <br>
> > > Support for out-of-tree builds, like BUILD_SHARED_LIBS or gn<br>
> > builds, are helpful for developers, but not relevant for release <br>
> > builds.<br>
> > <br>
> > I disagree. Out-of-tree builds are also very useful for downstream <br>
> > distributors when packaging individual components of the LLVM<br>
> > project.<br>
> > <br>
> > Isuru<br>
> > <br>
> > On Fri, Jul 31, 2020 at 2:45 PM Steve Scalpone via flang-dev < <br>
> > flang-dev@lists.llvm.org> wrote:<br>
> > > +1 on Pete's and Tim's reply. I am often building multiple<br>
> > > branches<br>
> > > at the same time.<br>
> > > From: flang-dev <flang-dev-bounces@lists.llvm.org> on behalf of <br>
> > > Peter Steinfeld via flang-dev <flang-dev@lists.llvm.org><br>
> > > Sent: Friday, July 31, 2020 12:23 PM<br>
> > > To: Michael Kruse <llvm@meinersbur.de><br>
> > > Cc: flang-dev@lists.llvm.org <flang-dev@lists.llvm.org><br>
> > > Subject: Re: [flang-dev] Out-of-tree flang builds<br>
> > > <br>
> > > External email: Use caution opening links or attachments<br>
> > > <br>
> > > Iterative builds are very useful and work well.<br>
> > > <br>
> > > <br>
> > > <br>
> > > But when I’m reviewing a change from someone else or starting on<br>
> > > a <br>
> > > new change for myself, I build all of flang. In the last six<br>
> > > hours, <br>
> > > I’ve done four non-iterative builds, for example.<br>
> > > <br>
> > > <br>
> > > <br>
> > > Pete<br>
> > > <br>
> > > <br>
> > > <br>
> > > From: Michael Kruse <llvm@meinersbur.de><br>
> > > Sent: Friday, July 31, 2020 12:01 PM<br>
> > > To: Peter Steinfeld <psteinfeld@nvidia.com><br>
> > > Cc: flang-dev@lists.llvm.org<br>
> > > Subject: Re: [flang-dev] Out-of-tree flang builds<br>
> > > <br>
> > > <br>
> > > <br>
> > > External email: Use caution opening links or attachments<br>
> > > <br>
> > > <br>
> > > <br>
> > > Support for out-of-tree builds, like BUILD_SHARED_LIBS or gn<br>
> > > builds, <br>
> > > are helpful for developers, but not relevant for release builds. <br>
> > > Requiring to maintain all combinations of build configurations<br>
> > > is <br>
> > > not feasible before every commit, this is why they are only best <br>
> > > effort. When you notice a out-of-tree build breaking, you are<br>
> > > free <br>
> > > to fix the problem (and assuming the fix is straightforward, <br>
> > > low-risk, without review).<br>
> > > <br>
> > > <br>
> > > <br>
> > > However, I am wondering, why isn't an iterative build sufficient?<br>
> > > Assuming you are not touching any non-flang files, make/ninja<br>
> > > should <br>
> > > not try to rebuild them.<br>
> > > <br>
> > > <br>
> > > Michael<br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > Am Fr., 31. Juli 2020 um 13:41 Uhr schrieb Peter Steinfeld via <br>
> > > flang-dev <flang-dev@lists.llvm.org>:<br>
> > > <br>
> > > > Out-of-tree builds are a way to build only the flang code using<br>
> > > > a <br>
> > > > pre-existing full build of llvm. Out-of-tree flang builds are <br>
> > > > four times faster than full builds. Thus, for those of us <br>
> > > > actively developing code and reviewing other people's changes, <br>
> > > > out-of-tree builds significantly improve our productivity.<br>
> > > > <br>
> > > > <br>
> > > > <br>
> > > > Unfortunately, out-of-tree builds are not currently supported<br>
> > > > by <br>
> > > > the llvm buildbots. Thus, people changing build files must<br>
> > > > test <br>
> > > > this feature themselves. The process of doing an out-of-tree <br>
> > > > build is described in the flang overview document -- <br>
> > > > <a href="https://github.com/llvm/llvm-project/tree/master/flang">https://github.com/llvm/llvm-project/tree/master/flang</a>.<br>
> > > > Alternatively, people changing build files could ask someone <br>
> > > > familiar with out-of-tree builds to review their changes.<br>
> > > > <br>
> > > > <br>
> > > > <br>
> > > > A recent update from David Truby broke out-of-tree builds -- <br>
> > > > <a href="https://reviews.llvm.org/D84022">https://reviews.llvm.org/D84022</a>. In the conversation in the
<br>
> > > > Phabricator review, David states that he understands that<br>
> > > > "out- <br>
> > > > of-tree builds are considered a "best effort" feature that<br>
> > > > isn't <br>
> > > > guaranteed to work". But since out-of-tree builds are<br>
> > > > critical <br>
> > > > for my development, I don't consider them optional.<br>
> > > > <br>
> > > > <br>
> > > > <br>
> > > > I'm writing this note to bring this issue to the broader flang <br>
> > > > community. I consider out-of-tree builds to be a critical<br>
> > > > feature <br>
> > > > that no change should break. What do you think?<br>
> > > > <br>
> > > > _______________________________________________<br>
> > > > flang-dev mailing list<br>
> > > > flang-dev@lists.llvm.org<br>
> > > > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev</a><br>
> > > > <br>
> > > <br>
> > > _______________________________________________<br>
> > > flang-dev mailing list<br>
> > > flang-dev@lists.llvm.org<br>
> > > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev</a><br>
> IMPORTANT NOTICE: The contents of this email and any attachments are<br>
> confidential and may also be privileged. If you are not the intended<br>
> recipient, please notify the sender immediately and do not disclose<br>
> the contents to any other person, use it for any purpose, or store or<br>
> copy the information in any medium. Thank you.<br>
</div>
</span></font></div>
</div>
</body>
</html>