Re: how to tell gnatmake to send executables to a different directory when compiling multi source?

["björn lundin" <b.f.lundin@gmail.com>]

On 29 Juli, 11:31, "Nasser M. Abbasi" <n...@12000.org> wrote:
> I have  --+---src/main1.adb, main2.adb
>            |
>            +---obj/
>            |
>            +---bin/
>
> In src/ I have few Ada main programs. I can build all and tell gnatmake
> to send the *.o and *.ali to the obj/ directory using -D switch.
>
> But not able to find an option to tell it send the generated
> executable (main1.exe and main2.exe) to bin/  directory.
>

I maintain a largish system, with 60+ executables,
some libraries written in C/C++,
linking with db-libraries
on AIX, Windows and now Linux.

The system was ported to gnat in 2002 by me, and at that time I found
gpr files to be
way to clumpsy. So I ended up with writing a frontend to gnatmake and
gcc that
* traversed the source dirs and created dummy ali files for each adb
and ads file.
* keeping a textfile as a 'ada library' ie, ability to have several
object directories

the frontend traverses the library file and builds a path of valid src
dirs and object dirs
and sets the ADA_INCLUDE_PATH resp ADA_OBJECT_PATH env vars.

by invoking the frontend from the correct/wanted target directory,
the frontend sets the env-vars, and runs gnatmake with a switch to
honor the exiting, but empty, ali-files
and links the exefile at the wanted location. the object files ends up
in their correct locations.
The only drawback is b* files generated by gnatbind. but the frontend
moves them to the obj directory when the exe is created.

This was driven by kornshell and bat files until a year ago, when I
started to build on Linux.
The kornshells (AIX) were not quite compatible with linux kornshell,
so I scrapped that double implemenation
and it is now driven by makefiles (yes recursive). One set of
makefiles for all platforms.

That is a ksh or bat calls the frontend, written in tcl, that calls
gnatmake.


it is stable and works very well.

If I would do it again, today? No.
Since that decision 10 years ago, gpr files has matured a lot.

I would use gpr, but I'd still use make to drive all compilation.
We also have some copying of different files to do, and auto
generation of some souce code (Ada),
and gpr does not handle that.

Main reason to use gpr today would be c.l.a, where there are many
experts on gpr.
lots of help to get. With your own tools, you are on your own.
Also eclipse/gps requires the use of gpr.



/Björn Lundin