On Monday, 25 November 2019 at 23:46:31 UTC, H. S. Teoh wrote:
> Oooh very nice!!  That's wonderful to hear.  So you're saying LDC out-of-the-box can cross-compile from Linux to Windows directly?  How to do this?  I'm *very* interested!

ldc2 -mtriple=x86_64-pc-windows-msvc

though you will prolly have to grab the druntime libs from the windows build.

this same basic thing works for android and mac os too.

On Tuesday, 26 November 2019 at 00:32:54 UTC, Adam D. Ruppe wrote:
> On Monday, 25 November 2019 at 23:46:31 UTC, H. S. Teoh wrote:
>> Oooh very nice!!  That's wonderful to hear.  So you're saying LDC out-of-the-box can cross-compile from Linux to Windows directly?  How to do this?  I'm *very* interested!
>
> ldc2 -mtriple=x86_64-pc-windows-msvc
>
> though you will prolly have to grab the druntime libs from the windows build.
>
> this same basic thing works for android and mac os too.

Or with dub:

dub build --arch=x86_64-pc-windows-msvc

You only need to provide windows libs from windows ldc package to your linux installation and tweak the config.
See https://wiki.dlang.org/Cross-compiling_with_LDC for details.

Using it every day now and it works like a charm.

On Tue, Nov 26, 2019 at 12:32:54AM +0000, Adam D. Ruppe via Digitalmars-d-announce wrote:
> On Monday, 25 November 2019 at 23:46:31 UTC, H. S. Teoh wrote:
> > Oooh very nice!!  That's wonderful to hear.  So you're saying LDC out-of-the-box can cross-compile from Linux to Windows directly? How to do this?  I'm *very* interested!
> 
> ldc2 -mtriple=x86_64-pc-windows-msvc
> 
> though you will prolly have to grab the druntime libs from the windows build.
> 
> this same basic thing works for android and mac os too.

Hmm. I tried this (test.d is a hello world program):

	ldc2 -mtriple=x86_64-pc-windows-msvc test.d

and got this:

	Error: failed to locate link.exe

Where am I supposed to get link.exe?


T

-- 
That's not a bug; that's a feature!

On Tue, Nov 26, 2019 at 01:19:58PM -0800, H. S. Teoh via Digitalmars-d-announce wrote:
> On Tue, Nov 26, 2019 at 12:32:54AM +0000, Adam D. Ruppe via Digitalmars-d-announce wrote:
[...]
> > ldc2 -mtriple=x86_64-pc-windows-msvc
> > 
> > though you will prolly have to grab the druntime libs from the windows build.
[...]

Tried installing the libs from the LDC windows build and editing ldc2.conf to setup the paths, etc., but still no go. It finally does find the linker and the Windows .lib's, but then it spews a whole bunch of undefined symbol errors.

Decided instead to just run the native Windows version of ldc2 under Wine (via wineconsole); works like a charm.  For now, at least for building Windows executables, I'm not gonna bother with cross-compiling. Wine appears to do the Right Thing(tm).


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley

On Tuesday, 26 November 2019 at 21:19:58 UTC, H. S. Teoh wrote:
> 	Error: failed to locate link.exe
>
> Where am I supposed to get link.exe?

You're supposed to consult the dedicated Wiki page linked by tchaloupka above (also linked in DMD 2.089 and LDC 1.18 release notes) in such a case, where you can read up on the used cross-linker, the -link-internally switch, and that it's supported in *official* prebuilt packages (i.e., the GitHub downloads, we don't officially support any distros). If you don't want to or cannot use the official package, then you can also install an external lld and use it via -linker=lld-link.

On Monday, 25 November 2019 at 23:46:31 UTC, H. S. Teoh wrote:
> Oooh very nice!!  That's wonderful to hear.  So you're saying LDC out-of-the-box can cross-compile from Linux to Windows directly?

Almost out of the box as mentioned; Windows targets are particularly simple (no need for a cross-gcc/clang toolchain). This has been possible for over 2 years now (LDC v1.3); the MS libs aren't required anymore starting with LDC v1.13. Glancing over the release notes does pay off sometimes. ;)

On Wed, Nov 27, 2019 at 12:24:11AM +0000, kinke via Digitalmars-d-announce wrote:
> On Tuesday, 26 November 2019 at 21:19:58 UTC, H. S. Teoh wrote:
> > 	Error: failed to locate link.exe
> > 
> > Where am I supposed to get link.exe?
> 
> You're supposed to consult the dedicated Wiki page linked by tchaloupka above (also linked in DMD 2.089 and LDC 1.18 release notes) in such a case,
[...]

I did consult the LDC cross-compiling page, and did modify ldc2.conf appropriately. But somewhere along the line I must have done something wrong, because it's still not cross-compiling properly. It's using the built-in LLD now, so the link.exe error is gone, but now it's coming back with a bunch of undefined druntime symbols even though I did specify the path to the prebuilt Windows druntime-ldc.lib in the ldc2.conf.

I gave up and resorted to installing the Windows build of ldc2 under Wine, and now I have a build script that uses wineconsole to compile Windows executables. :-P  So far, it appears to work.


T

-- 
Don't throw out the baby with the bathwater. Use your hands...

On Tue, Nov 26, 2019 at 05:10:41PM -0800, H. S. Teoh via Digitalmars-d-announce wrote: [...]
> I did consult the LDC cross-compiling page, and did modify ldc2.conf appropriately. But somewhere along the line I must have done something wrong, because it's still not cross-compiling properly. It's using the built-in LLD now, so the link.exe error is gone, but now it's coming back with a bunch of undefined druntime symbols even though I did specify the path to the prebuilt Windows druntime-ldc.lib in the ldc2.conf.
[...]

Just for the record, I finally figured out that it was a mistake on my part -- I overlooked some source files when testing the cross-compilation so that's why it had link errors.  After copying over the Windows libs and setting up ldc2.conf properly, cross-compilation to Windows does actually work flawlessly.

Absolutely awesome. Kudos to the LDC team for making this happen!!


T

-- 
A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White

On Monday, 25 November 2019 at 13:14:09 UTC, Sebastiaan Koppe wrote:
> On Monday, 25 November 2019 at 12:15:42 UTC, Joseph Rushton Wakeling wrote:
>> What's currently broken or impossible in DUB?  What parts of that can be fixed without changing the config or CLI?  And what improvements are most efficiently made via breaking changes?
>>
>> Please, let's bring our focus on that.
>
> The biggest thing for me would be incremental compilation.

https://github.com/atilaneves/reggae

Works right now with any (*) dub project.

* If it doesn't, please file a bug

On Monday, 25 November 2019 at 15:27:10 UTC, Robert Schadek wrote:
> On Monday, 25 November 2019 at 13:14:09 UTC, Sebastiaan Koppe wrote:
>> The biggest thing for me would be incremental compilation. As well as a dub build and test 'watch' mode to avoid scanning the dependencies every time.
>
> I think there are two levels to incremental compilation (IC).
>
> 1. File level IC. Meaning, if you have one file change, you only recompile
> all files that depend on that directly or transitively. Finally, you relink.


This is the done already by reggae. Unfortunately, since every D module is effectively a header, the number of files that need to be recompiled is usually large, despite the fact that for most changes the recompilation isn't actually necessary.


> For 1. my goal with dud is to do that. My first target is to emit ninja files.

That isn't going to work:

https://issues.dlang.org/show_bug.cgi?id=14188

reggae wraps dmd to act in a way that ninja can use. I'd also suggest that writing more ninja emitting code when reggae already does the job might be unnecessary.

The reason I stopped working on my own dub replacement is because I needed to attach to "a real build system", and since I want to rewrite reggae from scratch by building on the "Build Systems à la carte" paper...

On Thursday, 28 November 2019 at 13:10:44 UTC, Atila Neves wrote:
> This is the done already by reggae. Unfortunately, since every D module is effectively a header, the number of files that need to be recompiled is usually large, despite the fact that for most changes the recompilation isn't actually necessary.

Do you think it might work if it did dmd -H and make the auto-generated .di file and then did a content-based change detection on them for recompiling dependencies?

It'd prolly still do more work than it has to, but seeing .d changed, rebuild .di, if .di changed, rebuild other stuff might just avoid full rebuilds upon just simple function body changes.