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

Andrzej Warzynski via flang-dev flang-dev at lists.llvm.org
Sat Aug 1 13:21:56 PDT 2020


Sorry that this has been disruptive to people's workflows. When I was 
approving that patch I hoped that there was enough time for people to 
review, test or raise further objections.

Clearly some people rely on of out-of-tree builds while others require 
support for multi-config generators (IIUC, this is a prerequisite for 
Windows support). We should support both.

I also feel that out-of-tree builds are rather non-standard and rarely 
tested by developers (I never use it and AFAIK nobody on our team does). 
It sounds like Flang could benefit from a public build-bot that prevents 
this capability from future breakage.

In the meantime, I uploaded David's patch with the suggested fixes for 
out of tree builds here: https://reviews.llvm.org/D85078. I'm not a 
CMake expert, but both out-of-tree and multiconfig-generator builds 
worked on my machine. HTH

-Andrzej

On 31/07/2020 20:29, Michael Kruse via flang-dev wrote:
> Should by "incremental build", not "iterative build"
> 
> Michael
> 
> 
> Am Fr., 31. Juli 2020 um 14:01 Uhr schrieb Michael Kruse 
> <llvm at meinersbur.de <mailto:llvm at meinersbur.de>>:
> 
>     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 <mailto: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 <mailto: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
> 


More information about the flang-dev mailing list