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

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Vasiliy Molostov" <molostoff@gmail.com> writes:

> Ludovic Brenta <ludovic@ludovic-brenta.org> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Sun,
>> Been there, done that. Believe me: recursive make is the devil.  It is
>> insidious and perverse; it creates problems and cunningly hides them
>> from you.  You don't even know they exist until they come and bite you.
>> And of course, when they do you don't know where they come from.  The
>> irony is: just like the devil, you've created this mess yourself.
>
> Why people so warring against tools used by others? I wonder.

Well, I don't see any need for "war" here. ;-)
But anyway, I agree with Ludovic that recursive make
causes a lot of trouble, and is best avoided.

I can sympathize with the OP not wanting to learn about .gpr files
for simple projects, but in that case, a simple 'make' file
(non-recursive!) that invokes gnatmake can work well.
If you can't figure out how to get gnatmake to put the executables
where you want them, you can write some 'make' rules to copy them there.

> It is well known that appropriate tool utilization can give appropriate
> result, and vise versa.

I'm not sure what you mean by "vice versa" in this case, but appropriate
tool *choice* is also a good idea.  Learning about .gpr files isn't
trivial, but it won't kill you.  And you might want to look at
'gprbuild', which can deal with multi-language projects -- .gpr
is not just for Ada.

> Most open-source gnu c software are built using autotools with recursive
> make use, and it is ok.

I disagree that it is OK.  In my experience, recursive make leads to
complications and inefficiencies.  For small projects, the
inefficiencies might not matter, but I once converted a large
project from recursive make to non-recursive, and went from
over-10-hour builds to under-1-hour builds in the from-scratch
case, and even better speedups in the incremental re-build case.

Even for small projects, the difference between "few seconds" and
"go get a cup of coffee" involves forgetting one's train
of thought.

As for autotools, I think they are a nightmare, and totally unnecessary
for a language like Ada.  Gnat itself is built that way (because it's
part of gcc), and it's nothing but trouble.

> More productive is recursive and parallel make.

How about parallel gnatmake, or parallel gprbuild?  It's easy to write
race conditions using parallel make, but parallel gnatmake/gprbuild
doesn't have that problem.

>...And of course - handling
> "inter-goal" dependencies between subprojects
> in such recursive configuration is complex to describe in terms of
> makefile, but still possible.

Hmm.  I don't know any good way to deal with ``"inter-goal" dependencies
between subprojects'' via recursive 'make'.  Could you please outline
your techniques?  I don't much like 'make', but if I can learn some
better 'make' techniques, that's a good thing, since I have to deal
with it all the time!

- Bob