[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