Converting a simple makefile in a GPS project.

[Rego, P.]

I'm getting a bit difficult in converting this makefile in a .gpr project file.

-- makefile
all: main.hex main.lss sizedummy

program:
avrdude -pm8 <PROGRAMMER SPECIFIC> -Uflash:w:"main.hex"

main.elf: force
avr-gnatmake main -o $@ -Os -mmcu=avr4 --RTS=zfp -largs crtm8._o -nostdlib -lgcc -mavr4 -Tdata=0x00800200

main.lss: main.elf
-avr-objdump -h -S main.elf >"main.lss"

main.hex: main.elf
avr-objcopy -O ihex $< $@

sizedummy: main.elf
-avr-size --format=avr --mcu=atmega8 main.elf

clean:
$(RM) *.o leds *.ihex *.ali *.elf *.hex *.lss *.map

-- test.gpr
project Test is

for Source_Dirs use (".", "src");
for Object_Dir use "obj";
for Exec_Dir use "bin";
for Main use ("main.adb");

package Compiler is
for Default_Switches ("ada") use ("-gnatwa", "-gnat05");
end Compiler;

package Ide is
for Gnat use "avr-gnat";
for Gnatlist use "avr-gnatls";
for Debugger_Command use "avr-gdb";
end Ide;

end Test;

Where should I put each makefile sentence?

[Stephen Leake]

"Rego, P." <pvr...@gmail.com> writes:

> I'm getting a bit difficult in converting this makefile in a .gpr project file.
>
> -- makefile
> all: main.hex main.lss sizedummy
>
> program:
> avrdude -pm8 <PROGRAMMER SPECIFIC> -Uflash:w:"main.hex"

You can't teach gprbuild to do this, since it has no result file
(although I could be wrong).

> main.elf: force
> avr-gnatmake main -o $@ -Os -mmcu=avr4 --RTS=zfp -largs crtm8._o
> -nostdlib -lgcc -mavr4 -Tdata=0x00800200

Apparently you are using '.elf' as the 'executable extension'. That is
specified in 'package Builder', via 'Executable_Suffix' (see
gprbuild_ug.info, section 6.3 Package Builder).

The other options go in 'package Compiler' or 'package Linker'. It is
difficult to tell which; things following -largs probably go in Linker,
but you may have to experiment. The manual is no help here; I have
complained about this to AdaCore, to no avail.

> main.lss: main.elf
> -avr-objdump -h -S main.elf >"main.lss"

This just dumps the section headers into the .lss file. You might be
able to build a gprconfig file to teach gpr about this.
(gprbuild_ug.info section 5).

> main.hex: main.elf
> avr-objcopy -O ihex $< $@

Similarly, this converts a file from one format to another; you can
probably build a gprconfig file to do this.

> sizedummy: main.elf
> -avr-size --format=avr --mcu=atmega8 main.elf

I don't know what this does; possibly print a message to the output
stream giving the size? I don't think you can get gprbuild to do this.

> clean:
> $(RM) *.o leds *.ihex *.ali *.elf *.hex *.lss *.map

no way.

gprbuild is _not_ a complete replacement for make.

For the makefile you show (assuming it is complete), there is no
advantage to using a gpr file.

A gpr file is useful when you have several source directories, when you
need to specify different compilation options for different files, or
when you have a high-level project composed of lower-level projects.

--
-- Stephe

[Rolf]

Most of your Makefile rules cannot be expressed at all in GPR files
for gnatmake (I don't know about gprbuild). In your case, only the
rule for main.elf can be moved to a GPR file. See the examples in AVR-
Ada for a working mixture of Makefiles and GPR files.

Rolf

[Rego, P.]

> Apparently you are using '.elf' as the 'executable extension'. That is
> specified in 'package Builder', via 'Executable_Suffix' (see
> gprbuild_ug.info, section 6.3 Package Builder).
>
> The other options go in 'package Compiler' or 'package Linker'. It is
> difficult to tell which; things following -largs probably go in Linker,
> but you may have to experiment. The manual is no help here; I have
> complained about this to AdaCore, to no avail.
>

I tried to split the avr-gnatmake into
package Builder is
for Executable_Suffix use ".elf";
for Default_Switches ("Ada") use ("--RTS=zfp --mmcu=avr5");
end Builder;

package Linker is
for Default_Switches ("Ada") use ("tool\winavr-20100110\avr\lib\crtm8._o -nostdlib -lgcc -mavr5 -Tdata=0x00800200");
end Linker;

but still it returns me

avr-gnatmake -d -f -Pc:\test.gpr main.adb
avr-gnatmake: RTS path not valid: missing adainclude and adalib directories

[2012-04-21 16:48:27] process exited with status 4 (elapsed time: 00.10s)

[Rego, P.]

> Most of your Makefile rules cannot be expressed at all in GPR files
> for gnatmake (I don't know about gprbuild). In your case, only the
> rule for main.elf can be moved to a GPR file. See the examples in AVR-
> Ada for a working mixture of Makefiles and GPR files.

Thank you, good suggestion. I'm looking into AVR-Ada for finding this solution.

[Rego, P.]

(and thank you for your post :-) )

[Rego, P.]

> I tried to split the avr-gnatmake into
> package Builder is
> for Executable_Suffix use ".elf";
> for Default_Switches ("Ada") use ("--RTS=zfp --mmcu=avr5");
> end Builder;
>
> package Linker is
> for Default_Switches ("Ada") use ("tool\winavr-20100110\avr\lib\crtm8._o -nostdlib -lgcc -mavr5 -Tdata=0x00800200");
> end Linker;
>
> but still it returns me
>
> avr-gnatmake -d -f -Pc:\test.gpr main.adb
> avr-gnatmake: RTS path not valid: missing adainclude and adalib directories
>
> [2012-04-21 16:48:27] process exited with status 4 (elapsed time: 00.10s)

So now I am trying to configure the --RTS option in GPS. First I tried to include the two Windows Scenario variables ADAINCLUDE and ADALIB with the correct RTS path, but still the builder returns me the same error message ("avr-gnatmake: RTS path not valid: missing adainclude and adalib directories").

Secondly I tried to include the following lines inside .gpr file, but the result was the same.

type Ada_Include_Type is ("""c:\GNAT\2011\lib\gcc\avr\4.5.3\rts-zfp\adainclude""");
Ada_Include : Ada_Include_Type := external ("ADAINCLUDE", """c:\GNAT\2011\lib\gcc\avr\4.5.3\rts-zfp\adainclude""");

type Ada_Lib_Type is ("""c:\GNAT\2011\lib\gcc\avr\4.5.3\rts-zfp\adalib""");
Ada_Lib : Ada_Lib_Type := external ("ADALIB", """c:\GNAT\2011\lib\gcc\avr\4.5.3\rts-zfp\adalib""");

And finally I tried to set the path directly on package Builder, so I used

package Builder is
for Executable_Suffix use ".elf";

for Default_Switches ("Ada") use ("--RTS=c:\GNAT\2011\lib\gcc\avr\4.5.3\rts-zfp --mmcu=avr5");
end Builder;

and also the error message did not change.

Would someone have an idea on how to fix this?

[Stephen Leake]

"Rego, P." <pvr...@gmail.com> writes:

> I tried to split the avr-gnatmake into
> package Builder is
> for Executable_Suffix use ".elf";
> for Default_Switches ("Ada") use ("--RTS=zfp --mmcu=avr5");

This must be two strings:

for Default_Switches ("Ada") use ("--RTS=zfp", "--mmcu=avr5");

I doubt this is a Builder switch. Since gnatmake needs it, it's probably
a Compiler switch.

> end Builder;
>
> package Linker is
> for Default_Switches ("Ada") use ("tool\winavr-20100110\avr\lib\crtm8._o -nostdlib -lgcc -mavr5 -Tdata=0x00800200");
> end Linker;
>
> but still it returns me
>
> avr-gnatmake -d -f -Pc:\test.gpr main.adb
> avr-gnatmake: RTS path not valid: missing adainclude and adalib directories

Move the --RTS and --mmcu switches to other packages until it shows up here.

--
-- Stephe

[Simon Wright]

Stephen Leake <stephe...@stephe-leake.org> writes:

> This must be two strings:
>
> for Default_Switches ("Ada") use ("--RTS=zfp", "--mmcu=avr5");
>
> I doubt this is a Builder switch. Since gnatmake needs it, it's probably
> a Compiler switch.

I'm pretty sure that Builder => gnatmake.

gnatmake -h says
--RTS=dir specify the default source and object search path
.. should that be the full path?

[Rego, P.]

> This must be two strings:
>
> for Default_Switches ("Ada") use ("--RTS=zfp", "--mmcu=avr5");

Great! That was the mistake!! I was trying to call the switch "--RTS=zfp --mmcu=avr5", so the builder package understood that the RTS path was 'zfp --mmcu=avr5', instead of just 'zfp', and the rest was another switch. Other errors appeared, but I could solve them (below).

> I doubt this is a Builder switch. Since gnatmake needs it, it's probably
> a Compiler switch.

Actually that's half true. The "--RTS=zfp" is a Builder switch, but the "--mcu=avr5" is a Linker switch. I discovered because separating the strings caused other error, but the builder did not complain about the "--RTS=zfp".

> Move the --RTS and --mmcu switches to other packages until it shows up here.

So I kept moving the "--mcu=avr5" along the packages, and in Linker it worked. Also there were other problems in Linker switches, because I was also concatenating the other switches as a single strings (same problem as before), but fixing it, give it right.
Thank you.

[Rego, P.]

> > This must be two strings:
> >
> > for Default_Switches ("Ada") use ("--RTS=zfp", "--mmcu=avr5");
> >
> > I doubt this is a Builder switch. Since gnatmake needs it, it's probably
> > a Compiler switch.
>
> I'm pretty sure that Builder => gnatmake.

You were half right too. Actually as I answered to Stephen, the "--RTS=zfp" is a Builder switch, and the "--mmcu=avr5" may be a Linker switch.

> gnatmake -h says
> --RTS=dir specify the default source and object search path
> .. should that be the full path?

I had tried this before, but the big problem was the strings concatenation of the switches.
Thank you.

[Rego, P.]

Now I got to run all the line (and variants)

avr-gnatmake main -o $@ -Os -mmcu=avr4 --RTS=zfp -largs crtm8._o -nostdlib -lgcc -mavr4 -Tdata=0x00800200

from makefile. Now the next step is to include the lines in .gpr project file
(1) avr-objdump -h -S main.elf >"main.lss"
(2) avr-objcopy -O ihex $< $@

in a way that when I run Build, the Builder generates inside the bin folder the main.elf (already ok), the main.lss, and the main.hex files. The avr-size, avrdude and clean parts are not necessary; (the avrdude I can execute from an outside batch, no problem).

I looked into gprbuilder_ug documentation and there are lots of info, I did not find something like it. Maybe would exist a more direct way inside .gpr project?

[Stephen Leake]

"Rego, P." <pvr...@gmail.com> writes:

> Now I got to run all the line (and variants)
> avr-gnatmake main -o $@ -Os -mmcu=avr4 --RTS=zfp -largs crtm8._o -nostdlib -lgcc -mavr4 -Tdata=0x00800200
>
> from makefile. Now the next step is to include the lines in .gpr project file
> (1) avr-objdump -h -S main.elf >"main.lss"
> (2) avr-objcopy -O ihex $< $@

I'd have given up on gpr and kept the makefile, since it's simpler (and
better documented); why are you bothering with the gpr file?

> in a way that when I run Build, the Builder generates inside the bin
> folder the main.elf (already ok), the main.lss, and the main.hex
> files. The avr-size, avrdude and clean parts are not necessary; (the
> avrdude I can execute from an outside batch, no problem).
>
> I looked into gprbuilder_ug documentation and there are lots of info,
> I did not find something like it. Maybe would exist a more direct way
> inside .gpr project?

Here's what I use to run 'auto_text_io', which is similar. First,
auto_text_io.xml, in <gnat>/share/gprconfig:

<?xml version="1.0" ?>
<!-- Run auto_text_io

To tell gprbuild how to run auto_text_io:

copy this file to <gnat>/share/gprconfig

use gprbuild - -autoconf

-->
<gprconfig>
<compiler_description>
<name>Auto_Text_IO</name>
<executable>auto_text_io</executable>
<languages>Auto_Text_IO</languages>
<version>
<external>auto_text_io -?</external>
<grep regexp="auto_text_io version .*"/>
</version>
<!-- target must match gprconfig target -->
<target>
<external>${PREFIX}gcc -dumpmachine</external>
<grep regexp="[^\r\n]+"></grep>
</target>
</compiler_description>

<configuration>
<compilers>
<compiler language="Auto_Text_IO"/>
</compilers>
<config>
package Compiler is
for Driver ("Auto_Text_IO") use "${PATH}auto_text_io";
for Include_Path ("Auto_Text_IO") use "ADA_INCLUDE_PATH";
for Required_Switches ("Auto_Text_IO") use ("-f");
for Dependency_Switches ("Auto_Text_IO") use ("-M");
end Compiler;
package Naming is
for Body_Suffix ("Auto_Text_IO") use ".ads";
end Naming;
for Inherit_Source_Path ("Auto_Text_IO") use ("Ada");
for Object_Generated ("Auto_Text_IO") use "false";
</config>
</configuration>
</gprconfig>


Then a gpr file sal_text_io.gpr:

project SAL_Text_IO is
for Languages use ("Auto_Text_IO");
for Source_Dirs use
("../Source_Common");
for Object_Dir use "auto";
for Source_Files use
("sal-gen_math-gen_den_hart.ads",
"sal-gen_math-gen_dof_2.ads",
"sal-gen_math-gen_dof_3.ads",
"sal-gen_math-gen_dof_6.ads",
"sal-gen_math-gen_manipulator.ads",
"sal-gen_math-gen_polynomials.ads",
"sal-gen_math-gen_scalar.ads",
"sal-interfaces_more.ads",
"sal-time_conversions.ads");
end SAL_Text_IO;

and a makefile rule to run it:

text_io :
gprbuild -p -k --autoconf=../auto/auto.cgpr --target=x86-windows -Psal_text_io.gpr

Your application should be similar.

--
-- Stephe

[Rego, P.]

> I'd have given up on gpr and kept the makefile, since it's simpler (and
> better documented); why are you bothering with the gpr file?

I did not find a way of using the makefiles properly in GPS without having to configure the Build>Settings>Targets Compile/Build options and without messing up my OS configurations on other GPS projects (with other cross-compilers, etc); but actually I did not look for it harder. Running the makefiles from command-line or emacs is no problem, but I like to code using GPS stuffs, so I found that .gpr configs are easier (however the documentation does not help so much).

Thanks again. I will try it.

[Stephen Leake]

"Rego, P." <pvr...@gmail.com> writes:

>> I'd have given up on gpr and kept the makefile, since it's simpler (and
>> better documented); why are you bothering with the gpr file?
>

> I did not find a way of using the makefiles properly in GPS without
> having to configure the Build>Settings>Targets Compile/Build options
> and without messing up my OS configurations on other GPS projects
> (with other cross-compilers, etc); but actually I did not look for it

> harder. Running the makefiles from command-line of emacs is no

> problem, but I like to code using GPS stuffs, so I found that .gpr
> configs are easier (however the documentation does not help so much).

That's one reason I stick to Emacs :).

It is true that GPS has more advanced interactive GUI stuff than Emacs
Ada mode. I haven't tried it recently; I have recently tried Eclipse
(for Java), and I understand it's similar. I find all that eye candy
just gets in my way :). But some of the context sensitive menus are
nice; a list of parameters for a subprogram is helpful (although I'm not
clear how it handles overloaded programs).

You should report this as a GPS bug to AdaCore. I don't know that
they'll do anything about it, but they certainly won't if no one
complains :). If you explicitly state that "Emacs is better for this",
that might motivate them. Even better would be "Eclipse is better for
this" (if you know it to be true).

--
-- Stephe

[Rego, P.]

> It is true that GPS has more advanced interactive GUI stuff than Emacs
> Ada mode. I haven't tried it recently; I have recently tried Eclipse
> (for Java), and I understand it's similar. I find all that eye candy
> just gets in my way :). But some of the context sensitive menus are
> nice; a list of parameters for a subprogram is helpful (although I'm not
> clear how it handles overloaded programs).

I also tried gnatbench (plugin for Eclipse), but I yet think GPS is more mature than it, but sure it gives a good Ada flavor in Eclipse.

[Rego, P.]

Someone also suggested me this week adding a new menu in GPS, something like http://www.univ-orleans.fr/sciences/info/ressources/webada/doc/Gps/Adding-new-menus.html. It looks easy too.
Regards.