September 01, 2016
On 1 Sep 2016, at 21:43, Joseph Rushton Wakeling via digitalmars-d-ldc wrote:
> Just to confirm: will the %%ldcbinarypath%% wildcard be respected when passed to the `-gcc` flag?

See gen/configfile.cpp: %%ldcbinarypath%% will be replaced with the corresponding value when extracting the switches from the config file, so yes, it will also be respected for -gcc.

This, of course, does not apply when -gcc (or any other switch) is directly passed on the command line.

 — David
September 01, 2016
On Thursday, 1 September 2016 at 20:49:48 UTC, David Nadlinger wrote:
> On 1 Sep 2016, at 21:43, Joseph Rushton Wakeling via digitalmars-d-ldc wrote:
>> Just to confirm: will the %%ldcbinarypath%% wildcard be respected when passed to the `-gcc` flag?
>
> See gen/configfile.cpp: %%ldcbinarypath%% will be replaced with the corresponding value when extracting the switches from the config file, so yes, it will also be respected for -gcc.
>
> This, of course, does not apply when -gcc (or any other switch) is directly passed on the command line.

Sure; this is what I expected, just wanted to verify.

Anyway, I've encountered something weird with this (unless I'm missing something stupid).

First, is there _anything_ wrong per se with the following config file that would stop the -gcc flag getting through?

// This configuration file uses libconfig.
// See http://www.hyperrealm.com/libconfig/ for syntax details.

// The default group is required
default:
{
    // 'switches' holds array of string that are appends to the command line
    // arguments before they are parsed.
    switches = [
        "-I%%ldcbinarypath%%/../include/d/ldc",
        "-I%%ldcbinarypath%%/../include/d",
        "-L-L%%ldcbinarypath%%/../lib",
        "-defaultlib=phobos2-ldc,druntime-ldc",
        "-debuglib=phobos2-ldc-debug,druntime-ldc-debug",
        "-gcc=/snap/ldc2/x1/command-gcc.wrapper"
    ];
};

I ask because including the above in the snap package doesn't work, but if I _manually_ pass the -gcc flag after installing the snap:

    ldc2.ldmd2 -gcc=/snap/ldc2/x1/command-gcc.wrapper myprogram.d

... then this works.

That would suggest there's something about the snap-package containment that is making the path resolution mess up when it's specified inside the snap, but which is able to resolve the path correctly when it's given the full (from the outside system level) path to an executable that the containerized LDC can access.
September 01, 2016
On Thursday, 1 September 2016 at 21:14:37 UTC, Joseph Rushton Wakeling wrote:
> Anyway, I've encountered something weird with this (unless I'm missing something stupid).

OK, I _was_ missing something stupid.  I'd included an extra -gcc call courtesy of the snapcraft.yaml file.

Having -gcc=%%ldcbinarypath%%/../command-gcc.wrapper provide by the config file _does_ work.  I'll follow up later with a more extensive summary of things and a working example of the snap package.
1 2 3 4
Next ›   Last »