Re: gprbuild fun

[Simon Wright <simon@pushface.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 28 Jun 2015 18:28:13 +0100, Simon Wright wrote:
>
>> I have a mixed-language GPR like
>> 
>>    project build is
>>       for languages use ("ada", "c");
>>       for source_files use ("a.adb", "c.c");
>>       package ide is
>>          for compiler_command ("ada") use "gnatmake";
>>       end ide;
>>    end build;
>> 
>> (I have no idea why I introduced the compiler_command setting on
>> 2014-05-01, and I have no idea why the issue has only just surfaced)

I suppose I've only had arm-eabi-gcc on the path fairly recently, so
there wouldn't've been a cross-compiler to confuse matters.

>> and, if I have the native gcc and arm-eabi-gcc present in the PATH,
>> gprbuild chooses to use the native gcc for the Ada part and arm-eabi-gcc
>> for the C part!
>> 
>> Fix: delete the compiler_command line.
>
> Under Fedora ARM gprbuild is broken (wrong target). The fix is to rename it
> to /usr/bin/gprbuild.old and use
>
>    #!/bin/sh
>    gprbuild.old --target=armv7hl-redhat-linux-gnueabi $*
>
> instead. It is a pity that gnatmake is going to be ditched.

In this case, I could alternatively have invoked gprbuild with
--target=x86_64-apple-darwin13. But it shouldn't've been necessary!

I'm still quite baffled as to exactly where in the source gprbuild
invokes gprconfig with --target=all to cause the effect I saw. I suppose
it might just call it as a library.