gprbuild fun

gprbuild fun

[Simon Wright]

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)

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.

_That_ was fun.

Re: gprbuild fun

[Dmitry A. Kazakov]

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)
> 
> 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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: gprbuild fun

[David Botton]

No reason not to make a community effort for a set of build tools that is not as "delicate" as the gprtools and requires code outside the FSF tree to be compiled and used.

David Botton

Re: gprbuild fun

[vincent.diemunsch]

Le dimanche 28 juin 2015 21:22:33 UTC+2, David Botton a écrit :
> No reason not to make a community effort for a set of build tools that is not as "delicate" as the gprtools and requires code outside the FSF tree to be compiled and used.
> 
> David Botton

Sure. What could be the starting point ? Is gnatmake full FSF ? Could it be possible to add a sort of Ant or Maven written in Ada to replace GPR Build ? 

On idea : could it be possible to simply write the "makefile" in Ada then compile it first as an executable and use it to launch the rest of the compilation process ? To do that one only needs to develop a "building library" in Ada. No messy XML file required anymore !

Re: gprbuild fun

[David Botton]

> Sure. What could be the starting point ? Is gnatmake full FSF ? Could it be possible to add a sort of Ant or Maven written in Ada to replace GPR Build ? 

gnatmake is full FSF and part of the FSF tree. Once deprecated unless something changes it will no longer be possible to build an FSF GNAT using FSF tools. As it is, I doubt there will be future Windows 64 builds available already after 4.9.x unless we do something.


> On idea : could it be possible to simply write the "makefile" in Ada then compile it first as an executable and use it to launch the rest of the compilation process ? To do that one only needs to develop a "building library" in Ada. No messy XML file required anymore !

I don't think removing all dependencies on ASIS and XML are even a question for any future tool. gnatmake currently does not depend on either.

David Botton

Re: gprbuild fun

[vincent.diemunsch]

Le lundi 29 juin 2015 01:02:23 UTC+2, David Botton a écrit :
> > Sure. What could be the starting point ? Is gnatmake full FSF ? Could it be possible to add a sort of Ant or Maven written in Ada to replace GPR Build ? 
> 
> gnatmake is full FSF and part of the FSF tree. Once deprecated unless something changes it will no longer be possible to build an FSF GNAT using FSF tools. As it is, I doubt there will be future Windows 64 builds available already after 4.9.x unless we do something.

So the first priority is to save gnatmake as the FSF tool to build FSF GNAT !

I don't really understand what are the technical improvements of GPR Build over gnatmake. All I know is that even for a simple case of code generation using AYacc, I needed to create a makefile and an XML configuration file to use GPR Build... 


I thought that if I had a small Ada Library able to manage source files, object files and the equivalent of ".ali" files, I could write directly an Ada program that would call Ayacc and gnatmake, with not more work than creating makefiles and XML files.


Regards,

Vincent

Re: gprbuild fun

[Simon Wright]

vincent.diemunsch@gmail.com writes:

> So the first priority is to save gnatmake as the FSF tool to build
> FSF GNAT !

I don't see this changing; AdaCore aren't proposing to remove any of the
features of gnatmake that are actually used in the GCC build.

> I don't really understand what are the technical improvements of GPR
> Build over gnatmake. All I know is that even for a simple case of code
> generation using AYacc, I needed to create a makefile and an XML
> configuration file to use GPR Build...

So you were able to teach gprbuild how to handle AYacc? sounds good to
me!

Re: gprbuild fun

[Vincent]

Le lundi 29 juin 2015 10:36:55 UTC+2, Simon Wright a écrit :
> Vincent wrote :
> 
> > So the first priority is to save gnatmake as the FSF tool to build
> > FSF GNAT !
> 
> I don't see this changing; AdaCore aren't proposing to remove any of the
> features of gnatmake that are actually used in the GCC build.

Good news !

> 
> So you were able to teach gprbuild how to handle AYacc? sounds good to
> me!

No, sorry.. I simply got the response of using a makefile and a XML configuration for a new buildchain. Then I gave up with gprbuild and made a small script :-). That was enough for my need, even it is not satisfactory.

vincent

Re: gprbuild fun

[Simon Wright]

David Botton <david@botton.com> writes:

(in response to Vincent. David, could you get your newsreader to include
the person you're quoting?)

>> Sure. What could be the starting point ? Is gnatmake full FSF ? Could
>> it be possible to add a sort of Ant or Maven written in Ada to
>> replace GPR Build ?
>
> gnatmake is full FSF and part of the FSF tree. Once deprecated unless
> something changes it will no longer be possible to build an FSF GNAT
> using FSF tools. As it is, I doubt there will be future Windows 64
> builds available already after 4.9.x unless we do something.

The deprecated parts of gnatmake are the use of GPR project files and
the creation of libraries (which gnatmake doesn't do well anyway, at any
rate for Mac dylibs).

There are no project files in the FSF GCC build process (actually there
is one in the GCC tree, zlib/contrib/ada/zlib.gpr, imported from the
zlib project, which builds a testbed for the zlib ada binding but isn't
used by GCC itself).

>> On idea : could it be possible to simply write the "makefile" in Ada
>> then compile it first as an executable and use it to launch the rest
>> of the compilation process ? To do that one only needs to develop a
>> "building library" in Ada. No messy XML file required anymore !
>
> I don't think removing all dependencies on ASIS and XML are even a
> question for any future tool. gnatmake currently does not depend on
> either.

We're talking a build tool here, no reason not to use GPL code since the
compiler itself is GPL anyway! The only question is the RTS.

There's no use of ASIS in gprbuild.

XML is used as a handy :) way of holding a complex data structure in
text files. It's verbose, sure, and the way it's all put together is
reasonably obscure, but what gprbuild does with it is very useful.

Re: gprbuild fun

[Simon Wright]

"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.

Re: gprbuild fun

[Brian Drummond]

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;

> 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.

Presumably, ... editing it to arm-eabi-gnatmake would also work?

-- Brian

Re: gprbuild fun

[Mark Lorenzen]

On Monday, June 29, 2015 at 11:59:36 AM UTC+2, Brian Drummond wrote:
> 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;
> 
> > 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.
> 
> Presumably, ... editing it to arm-eabi-gnatmake would also work?
> 
> -- Brian

Why not simply state the target using the (appropriately named) Target project attribute and then build using gprbuild? We use Target and Runtime attributes and it works like a charm:

project xyz is

   for Languages use ("Ada");

   for Target use "leon3-elf";
   for Runtime ("Ada") use "ravenscar-full-leon3";
   ...

end XYZ;

Are these two attributes not supported by FSF GNAT (yet)?

We have moved our development from using gnatmake to gprbuild and we have never looked back. It simply works.

Regards,

MarkL

Re: gprbuild fun

[Simon Wright]

Mark Lorenzen <mark.lorenzen@gmail.com> writes:

> Why not simply state the target using the (appropriately named) Target
> project attribute and then build using gprbuild? We use Target and
> Runtime attributes and it works like a charm:

As I said to Brian, this was (intended to be!) a native build.

> project xyz is
>
>    for Languages use ("Ada");
>
>    for Target use "leon3-elf";
>    for Runtime ("Ada") use "ravenscar-full-leon3";
>    ...
>
> end XYZ;
>
> Are these two attributes not supported by FSF GNAT (yet)?

Both of them are supported in GPRBUILD GPL 2015, but GPRBUILD GPL 2014
doesn't support Runtime.

gnatmake doesn't do mixed-language builds, and won't support project
files in the next release (of FSF GCC, I presume):

   $ gnatmake -v -P build
   warning: gnatmake -P is obsolete and will not be available in the
   next release; use gprbuild instead

Re: gprbuild fun

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> 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;
>
>> 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.
>
> Presumably, ... editing it to arm-eabi-gnatmake would also work?

But I wanted the native version! --target=x86_64-apple-darwin13. Which
I've never had to say before.

As you suggest, for compiler_command ("ada") use "arm-eabi-gnatmake"
works, in the sense of selecting a consistent set of tools.

But the thing is, if you specify compiler_command, gprconfig is invoked
with e.g.

   gprconfig --batch -o /Users/simon/tmp/gprbuild-problem/auto.cgpr
   --target=all --config=c,, --config=ada,,,,gnatmake

but if you don't it's invoked with

   gprconfig --batch -o /Users/simon/tmp/gprbuild-problem/auto.cgpr
   --target=x86_64-darwin --config=c,, --config=ada,,

So where did it get --target=all from?! (and come to that where did
x86_64-darwin come from? x86_64-apple-darwin I would have understood)