<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>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Hi all, I meant to send this mail yesterday morning and instead managed to</div>
<div class="PlainText">direct reply to a limited number of people instead of the list. Sorry about that!</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">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 keep<br>
them working. What I am opposed to here is the idea that everyone must<br>
test every patch both in and out of tree or have their patch reverted,<br>
especially when out of tree configurations are not being built by any<br>
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 revert<br>
the patch that broke my build configuration, I simply posted a new<br>
patch to fix it). This patch underwent a review for 2 weeks before<br>
being approved and passed all the buildbots we have and as such I<br>
believe did not violate the criteria for a patch to be reverted<br>
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 option<br>
(such a fix could even have been committed without review given how<br>
simple it was).<br>
<br>
Obviously the revert broke my build configuration again, so the revert<br>
somewhat makes it feel that a decision was made off-list to consider<br>
one build configuration as more important than another. I think if we<br>
want out-of-tree builds to be considered more important than multi-<br>
config builds then that should be a decision made by the community not<br>
unilaterally. I also think if that decision is made then it must be<br>
defended by buildbots; if my patch had broken a buildbot I would have<br>
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 the<br>
> matter – whether out-of-tree builds are a critical feature.  If so,<br>
> Tim was right to revert.<br>
>  <br>
> It’s too bad that the buildbots don’t do out-of-tree builds.  In the<br>
> meanwhile, you can either do one yourself, as is documented here -- <br>
> <a href="https://github.com/llvm/llvm-project/tree/master/flang">https://github.com/llvm/llvm-project/tree/master/flang</a>.  Or you 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 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 configuration<br>
> fixed in every commit is an impossible task. I submitted the patch in<br>
> question because earlier builds broke my build configuration (and 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 is<br>
> reasonable.<br>
>  <br>
> I do not believe that this patch should have been reverted, as such a<br>
> revert seems to suggest that one (non-standard?) build configuration<br>
> (out of tree builds) is more important than another (non-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 the<br>
> LLVM Developer Guidelines guidance on quality of patches. I believe a<br>
> better course of action here would have been a patch from someone<br>
> that requires out-of-tree builds to work, and I submitted some<br>
> suggestions 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 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 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 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 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 a<br>
> > new change for myself, I build all of flang.  In the last six<br>
> > hours, 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, are helpful for developers, but not relevant for release<br>
> > builds. Requiring to maintain all combinations of build<br>
> > configurations is not feasible before every commit, this is why<br>
> > they are only best effort. When you notice a out-of-tree build<br>
> > breaking, you are free to fix the problem (and assuming the fix is<br>
> > straightforward, 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 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 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 by<br>
> > > the llvm buildbots.  Thus, people changing build files must 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 "out-<br>
> > > of-tree builds are considered a "best effort" feature that isn't<br>
> > > guaranteed to work".  But since out-of-tree builds are 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 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>
</div>
</span></font></div>
</div>
</body>
</html>