On Sunday, 28 August 2016 at 11:58:00 UTC, Joseph Rushton Wakeling wrote:
> 
> apps:
>   ldc2:
>     command: ldc2
>     plugs: [home]
>   ldmd2:
>     command: ldmd2
>     plugs: [home]

Don't know if it's relevant here, but `ldc-profdata` should also be part of the package :)

-Johan

On Sunday, 28 August 2016 at 13:28:33 UTC, kinke wrote:
> On Sunday, 28 August 2016 at 12:56:17 UTC, Joseph Rushton Wakeling wrote:
>> Is there any way of providing a similarly relative-to-compiler-path -I option to ldc2 and/or ldmd2 ... ?
>
> Of course; the Windows package is already portable.
> `%%ldcbinarypath%%` is replaced by the directory containing the ldc2 executable. So `-I%%ldcbinarypath%%/../include/d` etc. is the way to go.

OK, great, this works.  So, at a minimum, I can manually tweak things to guarantee that the final snap package will have a workable ldc2.conf.

Is there any way to get the build process of LDC to auto-generate the file with these relative paths including the %%ldcbinarypath%% wildcard ... ?  e.g. a cmake or make flag?

On Sunday, 28 August 2016 at 17:21:59 UTC, Johan Engelen wrote:
> On Sunday, 28 August 2016 at 11:58:00 UTC, Joseph Rushton Wakeling wrote:
>> 
>> apps:
>>   ldc2:
>>     command: ldc2
>>     plugs: [home]
>>   ldmd2:
>>     command: ldmd2
>>     plugs: [home]
>
> Don't know if it's relevant here, but `ldc-profdata` should also be part of the package :)

This is another binary generated as part of the LDC build?  I ask because I can't find it among the binaries generated.  Is it something new?

Thanks to everyone's help and advice, this remains the last major hurdle to getting a snap package completed:

On Sunday, 28 August 2016 at 11:58:00 UTC, Joseph Rushton Wakeling wrote:
> Finally, the snap-packaged LDC will currently fail at the linker stage, because (as I understand it) the snap package can't access regular system resources, only stuff that is in other snaps, and the core system snap doesn't include stuff like gcc.  So, building falls over with an error:
>
>     Error: failed to locate gcc
>
> There are a few long-term potential fixes here, including creating a snap that exposes GCC or a linker, but in the short term, I've been advised that probably the easiest way to create a reliable standalone LDC package is to bundle the linker into the snap.
>
> So, my question is, what would be the minimum requirements for a linker to accompany ldc2, and how would I ensure that the built ldc2 tries to use _that_ linker rather than some other one?

... could anyone advise ... ?

On Sunday, 28 August 2016 at 19:47:57 UTC, Joseph Rushton Wakeling wrote:
> Is there any way to get the build process of LDC to auto-generate the file with these relative paths including the %%ldcbinarypath%% wildcard ... ?  e.g. a cmake or make flag?

A single line in PowerShell suffices to replace a well-known build dir with the placeholder in the ldc2.conf file:
https://github.com/ldc-developers/ldc/blob/master/appveyor.yml#L144

> This is another binary generated as part of the LDC build?

Yes (ninja target: ldc-profdata, included by the default target).

On 28 Aug 2016, at 21:12, Joseph Rushton Wakeling via digitalmars-d-ldc wrote:
>> So, my question is, what would be the minimum requirements for a linker to accompany ldc2 […]
>
> ... could anyone advise ... ?

You need a GCC-compatible linker driver, which links in the C standard libraries. (The latter is the reason why (g)cc is used instead of ld.) You might need to pull in the full GCC package if there is no other way to depend on a C toolchain.

>> and how would I ensure that the built ldc2 tries to use _that_ linker rather than some other one?

You can set the CC environment variable when invoking LDC (or use the hidden "-gcc" option). Otherwise, we use llvm::findProgramByName("gcc"), which searches the PATH.

 — David

On Sunday, 28 August 2016 at 20:12:44 UTC, Joseph Rushton Wakeling wrote:
>> how would I ensure that the built ldc2 tries to use _that_ linker rather than some other one?

There's a hidden `-gcc=<pathToGcc>` switch supported by LDC. So I guess specifying that one in the default switches in the ldc2.conf file does the trick (e.g., `-gcc=%%ldcbinarypath/gcc`).
Not sure about the requirements, but shipping with both 32/64 bit libs would surely be nice. See https://github.com/ldc-developers/ldc/blob/master/driver/linker.cpp for some default libs and switches passed to the linker.

And yes, ldc-profdata is pretty new.

On Sunday, 28 August 2016 at 20:15:28 UTC, kinke wrote:
> On Sunday, 28 August 2016 at 19:47:57 UTC, Joseph Rushton Wakeling wrote:
>> Is there any way to get the build process of LDC to auto-generate the file with these relative paths including the %%ldcbinarypath%% wildcard ... ?  e.g. a cmake or make flag?
>
> A single line in PowerShell suffices to replace a well-known build dir with the placeholder in the ldc2.conf file:
> https://github.com/ldc-developers/ldc/blob/master/appveyor.yml#L144

Yea, and similarly I can use `sed` just fine on Linux.  I was just curious if there was a 'standard' way to do this that didn't involve search'n'replace.

>> This is another binary generated as part of the LDC build?
>
> Yes (ninja target: ldc-profdata, included by the default target).

Erm ... I've just done a completely fresh build of LDC v1.0.0 (freshly checked out from git), and there's no sign of an ldc-profdata binary.  Nor does make seem to know anything about and ldc-profdata target.

What am I missing? :-\

On Sunday, 28 August 2016 at 20:27:21 UTC, David Nadlinger wrote:
> You need a GCC-compatible linker driver, which links in the C standard libraries. (The latter is the reason why (g)cc is used instead of ld.) You might need to pull in the full GCC package if there is no other way to depend on a C toolchain.

Ouch!  But while that might be nasty to deal with short-term, in the long run it'll probably be possible to interact with a separate gcc snap.

>>> and how would I ensure that the built ldc2 tries to use _that_ linker rather than some other one?
>
> You can set the CC environment variable when invoking LDC (or use the hidden "-gcc" option). Otherwise, we use llvm::findProgramByName("gcc"), which searches the PATH.

OK, thanks.  I'll see what I can come up with package-wise ...

On Sunday, 28 August 2016 at 20:30:49 UTC, kinke wrote:
> There's a hidden `-gcc=<pathToGcc>` switch supported by LDC. So I guess specifying that one in the default switches in the ldc2.conf file does the trick (e.g., `-gcc=%%ldcbinarypath/gcc`).

Thanks, I'll look into that. :-)

> Not sure about the requirements, but shipping with both 32/64 bit libs would surely be nice. See https://github.com/ldc-developers/ldc/blob/master/driver/linker.cpp for some default libs and switches passed to the linker.

I agree.  Probably the first iteration of the package will just provide libs for the architecture it was built for, but a definite aim would be to have libs for multiple different architectures.

> And yes, ldc-profdata is pretty new.

I guess it's going to land in a stable release with v1.1 ... ?