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

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 30.07.12 13:16, Vasiliy Molostov wrote:
> Nasser M. Abbasi <nma@12000.org> писал(а) в своём письме Mon, 30 Jul 2012
> 07:01:11 +0400:
> 
>> On 7/29/2012 7:20 PM, Vasiliy Molostov wrote:
>>
> 
>> I see Make as the lowest common denominator. Unless GPRBUILD can
>> be used to build both Ada, Java, C, C++, etc.. and can be used also
>> to invoke latex to update my pdf files and HTML web pages when my
>> .tex files changes, and I can use it to do my backups and all
>> the other tasks I use Make for, then I do not see something better
>> as a general tool.
> 
> Agree. A general tool is more useful than specialized one, of course.
> 
>> Only problem was when it comes to sending the object files
>> and the .exe to different places during the build. Ada is more
>> complicated and has more intermediate files generated.  If one
>> does not mind keeping all files generated in the same folder as
>> the sources, then the above is all what is needed for a basic
>> Ada project build.
> 
> So the problem here is how GNAt generates its output, and it is not
> related to make by itself, and can not turn other things into a devil.

You mean, compilation processes, in phases, number of intermediate
files, etc., should be kept simple and few, so that proud Make
loving people can continue doing what they seem to be doing?

I do use Make for auxiliary tasks. For starting tests runs.
For packaging. For transforming documentation. So don't get me wrong.
I like Make.

And indeed, Ada won't turn anything into anything else when that
already is. But it will expose a state of things with C files
and Make. That's the point: it lets you see things.

If a language defines "elaboration", if it states what it means
for one unit to depend on another, in source, and if a language
requires that compilers address the issue, then this language
create processes of production that are necessarily different
from what you get with C.

IMHO, the difference between Ada and C here shows a big blind
spot in the C world, one that can create cost of development and
frustrated programmers (porting software): a tool that is not
covered by the C standard. The blind spot has two aspects, and,
correspondingly, there are two ways of ignoring the blind spot,
blissfully, even after learning about it:

1) [socially] Since frustration and cost of preparing C source
files for compilation are ubiquitous, it is taken as normal.  It
will take something like the Ada experience to make them appear
as *not* normal if seen across language definitions. But this
new insight won't matter since everybody writes Makefiles (And,
for that matter, uses auto****, another non-C thing that could
not exist but for hysteric raisins).

2) [individually] C is a can-do-it language, top to almost
bottom. (Ada is more of a has-it language.) Therefore, can-do-it
people writing C will secure an opportunity of being proud of
having managed dependencies themselves (I-can-do-it).  So, for
any one given point in time, they have managed the dependencies
for the current set of C sources. Great!

Taken together, naturally, adding a working set of definitions
relating to dependence to C is fenced off, not only on the
ground that this reduces flexibility in individual cases, but
also becuase this addition would seem to take away your favorite
toys.

The Ada experience lets you see the devil in the details, when
it comes to all those changes. Bob Duff gave an example (of
compilation time being a tenth or less). Changes in the C world
require programmers who know both C and the dependency graph of
the entire software. Hence, this creates more opportunities for
more integration tests, all unneccessary to the extent that your
language defines dependence.

3) [economically] C is a good language for a business model
focussing on a certain class of tools dealing with dependence
of C source files, such as Make. Use the blind spot for gain.