[flang-dev] Out-of-tree flang builds

[Isuru Fernando via flang-dev]

> Support for out-of-tree builds, like BUILD_SHARED_LIBS or gn builds, are
helpful for developers, but not relevant for release builds.

I disagree. Out-of-tree builds are also very useful for downstream
distributors when packaging individual components of the LLVM project.

Isuru

On Fri, Jul 31, 2020 at 2:45 PM Steve Scalpone via flang-dev <
flang-dev at lists.llvm.org> wrote:

> +1 on Pete's and Tim's reply. I am often building multiple branches at the
> same time.
> ------------------------------
> *From:* flang-dev <flang-dev-bounces at lists.llvm.org> on behalf of Peter
> Steinfeld via flang-dev <flang-dev at lists.llvm.org>
> *Sent:* Friday, July 31, 2020 12:23 PM
> *To:* Michael Kruse <llvm at meinersbur.de>
> *Cc:* flang-dev at lists.llvm.org <flang-dev at lists.llvm.org>
> *Subject:* Re: [flang-dev] Out-of-tree flang builds
>
> *External email: Use caution opening links or attachments*
>
> Iterative builds are very useful and work well.
>
>
>
> But when I’m reviewing a change from someone else or starting on a new
> change for myself, I build all of flang.  In the last six hours, I’ve done
> four non-iterative builds, for example.
>
>
>
> Pete
>
>
>
> *From:* Michael Kruse <llvm at meinersbur.de>
> *Sent:* Friday, July 31, 2020 12:01 PM
> *To:* Peter Steinfeld <psteinfeld at nvidia.com>
> *Cc:* flang-dev at lists.llvm.org
> *Subject:* Re: [flang-dev] Out-of-tree flang builds
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
> Support for out-of-tree builds, like BUILD_SHARED_LIBS or gn builds, are
> helpful for developers, but not relevant for release builds. Requiring to
> maintain all combinations of build configurations is not feasible before
> every commit, this is why they are only best effort. When you notice a
> out-of-tree build breaking, you are free to fix the problem (and assuming
> the fix is straightforward, low-risk, without review).
>
>
>
> However, I am wondering, why isn't an iterative build sufficient? Assuming
> you are not touching any non-flang files, make/ninja should not try to
> rebuild them.
>
>
> Michael
>
>
>
>
>
>
>
> Am Fr., 31. Juli 2020 um 13:41 Uhr schrieb Peter Steinfeld via flang-dev <
> flang-dev at lists.llvm.org>:
>
> Out-of-tree builds are a way to build only the flang code using a
> pre-existing full build of llvm.  Out-of-tree flang builds are four times
> faster than full builds.  Thus, for those of us actively developing code
> and reviewing other people's changes, out-of-tree builds significantly
> improve our productivity.
>
>
>
> Unfortunately, out-of-tree builds are not currently supported by the llvm
> buildbots.  Thus, people changing build files must test this feature
> themselves.  The process of doing an out-of-tree build is described in the
> flang overview document --
> https://github.com/llvm/llvm-project/tree/master/flang.  Alternatively,
> people changing build files could ask someone familiar with out-of-tree
> builds to review their changes.
>
>
>
> A recent update from David Truby broke out-of-tree builds --
> https://reviews.llvm.org/D84022.  In the conversation in the Phabricator
> review, David states that he understands that "out-of-tree builds are
> considered a "best effort" feature that isn't guaranteed to work".  But
> since out-of-tree builds are critical for my development, I don't consider
> them optional.
>
>
>
> I'm writing this note to bring this issue to the broader flang community.
> I consider out-of-tree builds to be a critical feature that no change
> should break.  What do you think?
>
> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev
>
> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20200731/f6fdab1b/attachment.html>