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

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

"Nasser M. Abbasi" <nma@12000.org> writes:
> On 7/29/2012 8:49 AM, Ludovic Brenta wrote:
>>> Here is very simple note on using recusive Make
>>>
>>> http://12000.org/my_notes/cheat_sheets/make_notes/index.htm
>
>> And here is a very detailed note about why *not* to use recursive Make:
>>
>> http://miller.emu.id.au/pmiller/books/rmch/
>
> I know about this, and read it. It is a 'popular' link every time one
> says recursive make.
>
> All what it boils to, is that recursive make is not efficient. Ok. Big
> deal. I can wait 5 more seconds.  I have an 8 quad PC and lots of ram
> :)

No. The most important point is that recursive make defeats dependency
management.  This makes it virtually impossible to guarantee safe
compilation, *especially* with languages other than Ada, which do not
guarantee or enforce the consistency of source files with object files,
or of object files with one another.

> I have been using recursive make for years, never seen a problem. So I
> do not need a 'paper' written 15 years ago to tell it is a bad idea.

You have been hiding potential problems for years, then.  No wonder you
didn't see them.

> I run make from the top of my tree, go make coffee, check my mail, or
> take a short nap, and then it is done. It is really never been an
> issue for me. so why fix what is not broken :)

Running recursive make from the top of the tree is only half the
solution.  The full solution is to delete all files produced during the
recursive make, then re-launch it again.  This is a solution to a
totally artificial problem (i.e. defeating dependency management)
created by recursive make.  And, of course, the solution of deleting all
products of the compilation (object files, .ali files, executables,
shared libraries, documentation, etc) *cannot* be implemented by
recursive make, since recursive make creates the *problem*.

> But this is for my personal use. May be for a large company with
> millions of lines of code, then it is an issue. I do not know. There
> are always things one can do to improve anything they do I
> suppose. The problem is to pick the stuff that is most important to
> improve on.

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.

-- 
Ludovic Brenta.