[flang-dev] CMake standalone and compile flags

[Mehdi AMINI via flang-dev]

On Mon, May 4, 2020 at 10:41 AM Isuru Fernando <isuruf at gmail.com> wrote:

>
>
> On Mon, May 4, 2020 at 12:30 PM Mehdi AMINI via flang-dev <
> flang-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Mon, May 4, 2020 at 10:17 AM David Truby <David.Truby at arm.com> wrote:
>>
>>> Hi Mehdi,
>>>
>>> That branch enables out of tree builds; I believe there are people that
>>> still rely on those which is why we added that branch in when rewriting the
>>> CMake infrastructure.
>>>
>>
>> I assume that folks were relying on this before the merge in the
>> monorepo, but are there still reason to maintain this from now on? Can we
>> put an end-date on it?
>> I'm trying to figure out if this is just a transition thing or if this is
>> really something useful on the long run (and why).
>>
>
> Most LLVM subprojects have out-of-tree builds. For eg: clang, lld, lldb,
> libcxx, openmp, clang-rt  and it's a useful option to have.
>

But I'd claim that most of them only have this because that was the norm
until 6 months ago when everything merged in the monorepo :)
(builtin/runtime libraries are a different case though, they often must
built against a just-built compiler)

Tim had a good point about the usefulness of it though: scaling the builds
of multiple flang variants against the same LLVM. I wonder how fragile /
useful is this though (I never done so)? You likely have to disable
LLVM_ABI_BREAKING_CHECKS if you're trying to build a Debug flang against a
release LLVM (or vice versa). If your LLVM is not a Debug one you also
don't have debug info for the LLVM data structure / libraries, this may be
limiting when debugging flang.


> mlir is an exception.
>

That's because it is the only project that started *after* the monorepo was
a thing and always assumed it.

-- 
Mehdi



>
> Isuru
>
>
>>
>>
>>> There's an open review to fix a similar issue as is reported in the
>>> discussion you linked but it seems to have stalled on a discussion about
>>> whether to continue to force Werror on, perhaps you could take a look at
>>> that and comment there if it fixes this issue or not?
>>>
>>> The review is at https://reviews.llvm.org/D78306
>>>
>>
>> Thanks, that was roughly what I was about to start doing!
>> In general I think we should avoid doing directly `set(CMAKE_CXX_FLAGS
>> ...` and instead use the `add_flag_if_supported` macros provided by LLVM,
>> e.g.:
>> https://github.com/llvm/llvm-project/blob/master/mlir/lib/CMakeLists.txt#L2
>>
>> Werror is always difficult to maintain because different compilers (and
>> compiler versions) have different handling (possibly even opposite!)
>> warnings. It is a good thing to have for developers, but it may be a bit
>> hostile to users to have it on by default.
>>
>> --
>> Mehdi
>>
>>
>>
>>>
>>>
>>> Thanks
>>> David Truby
>>> ------------------------------
>>> *From:* flang-dev <flang-dev-bounces at lists.llvm.org> on behalf of Mehdi
>>> AMINI via flang-dev <flang-dev at lists.llvm.org>
>>> *Sent:* 04 May 2020 18:12
>>> *To:* Flang Development List <flang-dev at lists.llvm.org>
>>> *Subject:* [flang-dev] CMake standalone and compile flags
>>>
>>> Hi,
>>>
>>> I was looking into fixing this error that someone has when building
>>> flang: https://llvm.discourse.group/t/error-when-building-with-cmake/935
>>>
>>> Then I noticed that flang/CMakeLists.txt still has this branch:
>>> https://github.com/llvm/llvm-project/blob/master/flang/CMakeLists.txt#L42
>>> ; is there anyone that relies on it or can we simplify this file and the
>>> way the options are setup?
>>>
>>> Thanks,
>>>
>>> --
>>> Mehdi
>>>
>>> _______________________________________________
>> 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/20200504/bf6bcae7/attachment.html>