I'm working on building LDC in tag v1.18.0.

I cloned LDC with `--recursive`  option, checked out tag v1.18.0, and execute cmake like below:

```
mkdir build
cd build
cmake ..
```

But I got the error in cmake execution:
```
CMake Error at /usr/lib/cmake/llvm/LLVMExports.cmake:37 (message):
  Some (but not all) targets in this export set were already defined.

  Targets Defined: FileCheck;not

  Targets not yet defined:
....
```

After investigating, I found the cause is that cmake target "FileCheck`" and "not" are already defined in "ldc/utils/CMakeLists.txt`".
I thought that "ldc/utils/CMakeLists.txt`" is written to be loaded after including LLVMConfig because there are some checks for existence of those targets, which is defined in LLVMConfig.
But actually "ldc/utils/CMakeLists.txt`" is loaded before LLVMConfig.
I cannot understand why this can be built.

What should I do for building LDC successfully?

My operating system is Arch Linux and LLVM version is 9.0.0.

On 2019-10-29 08:04, Sobaya wrote:
> I'm working on building LDC in tag v1.18.0.
> 
> I cloned LDC with `--recursive`  option, checked out tag v1.18.0, and execute cmake like below:
> 
> ```
> mkdir build
> cd build
> cmake ..
> ```
> 
> But I got the error in cmake execution:
> ```
> CMake Error at /usr/lib/cmake/llvm/LLVMExports.cmake:37 (message):
>    Some (but not all) targets in this export set were already defined.
> 
>    Targets Defined: FileCheck;not
> 
>    Targets not yet defined:
> ....
> ```
> 
> After investigating, I found the cause is that cmake target "FileCheck`" and "not" are already defined in "ldc/utils/CMakeLists.txt`".
> I thought that "ldc/utils/CMakeLists.txt`" is written to be loaded after including LLVMConfig because there are some checks for existence of those targets, which is defined in LLVMConfig.
> But actually "ldc/utils/CMakeLists.txt`" is loaded before LLVMConfig.
> I cannot understand why this can be built.
> 
> What should I do for building LDC successfully?
> 
> My operating system is Arch Linux and LLVM version is 9.0.0.

Not sure if it's related, but you need to run "git submodule update --recursive" after checking out a tag.

-- 
/Jacob Carlborg

On Tuesday, 29 October 2019 at 13:21:49 UTC, Jacob Carlborg wrote:
> On 2019-10-29 08:04, Sobaya wrote:

Where's the original msg? It doesn't show up in the web interface.

>> After investigating, I found the cause is that cmake target "FileCheck`" and "not" are already defined in "ldc/utils/CMakeLists.txt`".
>> I thought that "ldc/utils/CMakeLists.txt`" is written to be loaded after including LLVMConfig because there are some checks for existence of those targets, which is defined in LLVMConfig.
>> But actually "ldc/utils/CMakeLists.txt`" is loaded before LLVMConfig.
>> I cannot understand why this can be built.

Looks like it depends on how LLVM was built plus it seems LLVM 9 related. It works fine with our prebuilt LLVM 9 as well as the official prebuilt LLVM 9 from llvm.org.
This (https://github.com/ldc-developers/ldc/issues/3079) and similar CMake issues are fixed in master now (see https://github.com/ldc-developers/ldc/pull/3198).

On Tuesday, 29 October 2019 at 13:21:49 UTC, Jacob Carlborg wrote:
> On 2019-10-29 08:04, Sobaya wrote:
>> [...]
>
> Not sure if it's related, but you need to run "git submodule update --recursive" after checking out a tag.

I've already run recursive submodule update.

On Tuesday, 29 October 2019 at 13:55:28 UTC, kinke wrote:
> On Tuesday, 29 October 2019 at 13:21:49 UTC, Jacob Carlborg wrote:
>> On 2019-10-29 08:04, Sobaya wrote:
>
> Where's the original msg? It doesn't show up in the web interface.
>
>>> [...]
>
> Looks like it depends on how LLVM was built plus it seems LLVM 9 related. It works fine with our prebuilt LLVM 9 as well as the official prebuilt LLVM 9 from llvm.org.
> This (https://github.com/ldc-developers/ldc/issues/3079) and similar CMake issues are fixed in master now (see https://github.com/ldc-developers/ldc/pull/3198).

Surely I succeeded on master branch, but why this bug is remained at release tag?

On Tuesday, 29 October 2019 at 18:12:36 UTC, Sobaya wrote:
> Surely I succeeded on master branch, but why this bug is remained at release tag?

1.18 is 13 days old, the fix was merged 8 days ago, and the latent issue has been there for months if not years and has only become acute now with, as explained, *some* LLVM 9 configs.

On Tuesday, 29 October 2019 at 19:36:49 UTC, kinke wrote:
> On Tuesday, 29 October 2019 at 18:12:36 UTC, Sobaya wrote:
>> Surely I succeeded on master branch, but why this bug is remained at release tag?
>
> 1.18 is 13 days old, the fix was merged 8 days ago, and the latent issue has been there for months if not years and has only become acute now with, as explained, *some* LLVM 9 configs.

Thank you.
Then I'll try to work in master branch.

On 2019-10-29 14:55, kinke wrote:

> Where's the original msg? It doesn't show up in the web interface.

I don't know. I'm using the newsgroup interface.

-- 
/Jacob Carlborg

On Wednesday, 30 October 2019 at 04:08:18 UTC, Sobaya wrote:
> On Tuesday, 29 October 2019 at 19:36:49 UTC, kinke wrote:
>> On Tuesday, 29 October 2019 at 18:12:36 UTC, Sobaya wrote:
>>> Surely I succeeded on master branch, but why this bug is remained at release tag?
>>
>> 1.18 is 13 days old, the fix was merged 8 days ago, and the latent issue has been there for months if not years and has only become acute now with, as explained, *some* LLVM 9 configs.
>
> Thank you.
> Then I'll try to work in master branch.

I tried but get an error "Option 'mc-relax-all' registered more than once!".

On Wednesday, 30 October 2019 at 12:07:50 UTC, Sobaya wrote:
> I tried but get an error "Option 'mc-relax-all' registered more than once!".

See https://wiki.dlang.org/Building_LDC_from_source - you'll need to set LDC_WITH_LLD=OFF (I guess you're linking against the shared LLVM library...).