Jump to page: 1 2
Thread overview
October 20
I am trying to build LDC, but get errors like this:

Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file /opt/local/libexec/llvm-10/include/llvm/IR/DataLayout.h, line 625.

October 20
On Tuesday, 20 October 2020 at 18:13:16 UTC, Ola Fosheim Grøstad wrote:
> I am trying to build LDC, but get errors like this:
>
> Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file /opt/local/libexec/llvm-10/include/llvm/IR/DataLayout.h, line 625.

Sure, LLVM 6.0+ is supported. You're 'just' hitting an LLVM assertion here, probably because of an earlier LDC bug. As you hit it when building LDC, that's either the host compiler or the fresh compiler compiling druntime/Phobos.
October 21
On Tuesday, 20 October 2020 at 22:18:37 UTC, kinke wrote:
> Sure, LLVM 6.0+ is supported. You're 'just' hitting an LLVM assertion here, probably because of an earlier LDC bug. As you hit it when building LDC, that's either the host compiler or the fresh compiler compiling druntime/Phobos.

Ok, I tried to build "master" with LLVM10. I didn't get the assertion failure when I built with LLVM11.

Whenever I modify some d code and rebuild with ninja, then building ldc2.o is somewhat slow. I believe I am building using "Debug" target setting. Is there some way to speed this up?

October 21
On Wednesday, 21 October 2020 at 07:19:24 UTC, Ola Fosheim Grøstad wrote:
> Whenever I modify some d code and rebuild with ninja, then building ldc2.o is somewhat slow.

Yes, by default, the entire frontend is compiled to a single object file. Use `-DCOMPILE_D_MODULES_SEPARATELY=ON` in the CMake cmdline to compile each module separately (https://github.com/ldc-developers/ldc/blob/37a27eb9e558669afe5deacadd5780d5542fdcba/CMakeLists.txt#L142).
October 21
On Wednesday, 21 October 2020 at 12:17:01 UTC, kinke wrote:
> On Wednesday, 21 October 2020 at 07:19:24 UTC, Ola Fosheim Grøstad wrote:
>> Whenever I modify some d code and rebuild with ninja, then building ldc2.o is somewhat slow.
>
> Yes, by default, the entire frontend is compiled to a single object file. Use `-DCOMPILE_D_MODULES_SEPARATELY=ON` in the CMake cmdline to compile each module separately (https://github.com/ldc-developers/ldc/blob/37a27eb9e558669afe5deacadd5780d5542fdcba/CMakeLists.txt#L142).

Makes sense. Separate compilation makes more sense for tweaking. Thanks!

October 28
On Wednesday, 21 October 2020 at 12:17:01 UTC, kinke wrote:
> On Wednesday, 21 October 2020 at 07:19:24 UTC, Ola Fosheim Grøstad wrote:
>> Whenever I modify some d code and rebuild with ninja, then building ldc2.o is somewhat slow.
>
> Yes, by default, the entire frontend is compiled to a single object file. Use `-DCOMPILE_D_MODULES_SEPARATELY=ON` in the CMake cmdline to compile each module separately (https://github.com/ldc-developers/ldc/blob/37a27eb9e558669afe5deacadd5780d5542fdcba/CMakeLists.txt#L142).

Just a question, when forking LDC, is there anything I really need to change in order to not cause confusion? I wasn't really sure how to deal with the LICENSE, so I rewrote it like this:

https://github.com/OlaFosheimGrostad/dex/blob/master/LICENSE

Please let me know if I should have done it in a different way.

November 10
On Wednesday, 21 October 2020 at 12:17:01 UTC, kinke wrote:
> On Wednesday, 21 October 2020 at 07:19:24 UTC, Ola Fosheim Grøstad wrote:
>> Whenever I modify some d code and rebuild with ninja, then building ldc2.o is somewhat slow.
>
> Yes, by default, the entire frontend is compiled to a single object file. Use `-DCOMPILE_D_MODULES_SEPARATELY=ON` in the CMake cmdline to compile each module separately

Hm. When I change dmd's parse.d and do "ninja ldc2" it does not detect the change?

November 10
On Tuesday, 10 November 2020 at 15:47:21 UTC, Ola Fosheim Grøstad wrote:
> Hm. When I change dmd's parse.d and do "ninja ldc2" it does not detect the change?

IIRC, the dmd.parse module is recompiled and ldc2 re-linked. Transitive dependencies aren't handled, i.e., other unchanged modules importing dmd.parse aren't recompiled.
January 10
On Tuesday, 10 November 2020 at 17:18:20 UTC, kinke wrote:
> On Tuesday, 10 November 2020 at 15:47:21 UTC, Ola Fosheim Grøstad wrote:
>> Hm. When I change dmd's parse.d and do "ninja ldc2" it does not detect the change?
>
> IIRC, the dmd.parse module is recompiled and ldc2 re-linked. Transitive dependencies aren't handled, i.e., other unchanged modules importing dmd.parse aren't recompiled.

I can't really make the build scripts work as I would expect them to.

For instance, after removing a file and executing "ninja clean":

$ ninja clean ldc2
ninja: error: '…dirpath…/parse_d4.d', needed by 'obj/ldc2.o', missing and no known rule to make it


January 10
On Sunday, 10 January 2021 at 09:30:13 UTC, Ola Fosheim Grøstad wrote:
> For instance, after removing a file and executing "ninja clean":
>
> $ ninja clean ldc2
> ninja: error: '…dirpath…/parse_d4.d', needed by 'obj/ldc2.o', missing and no known rule to make it

You'll probably have to re-run CMake to have the ninja scripts updated, removing the vanished source file. I guess that's the price to pay for globbing the source files. - Without a dirty source tree, i.e., when git-committing the changes before a build, ninja re-runs CMake automatically.
« First   ‹ Prev
1 2