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

["Vasiliy Molostov" <molostoff@gmail.com>]

Ludovic Brenta <ludovic@ludovic-brenta.org> писал(а) в своём письме Mon,  
30 Jul 2012 10:40:28 +0400:

> No, even in C an object file corresponds to not one but *several* input
> files: one or possibly several *.c and many *.h files.  Make was
> invented to compensate for the deficiencies of C, which does not track
> dependencies, and Make does a bad job of that, even in simple projects.

As we can see from predefined make rules

%.o: %.c

which means that C input source file has a direct correspondence to a  
resulting object file, and which is not applicable to gnat ada sources at  
all. Make is a general tool supporting that strict input-output pairing  
correspondence approach.

As for dependencies of C code and header files (*.h) they are come from  
gcc autogenerated dependencies, lately included into makefile as a part.  
And indeed it is a helper, since a hand intervention is still might be  
required to express an author wish.

The way it works is similar to all C stuff, someone has even named it as  
dancing with a blade. Is it danger? Perhaps. Is it devil?

>> But why the "recursive" is devil? Usual project contains many files
>> that needs to be built, not only source code, but data, man pages and
>> docs,  configurations, all these are separate and usually built via
>> recursive  makefiles.
>
> Just because many lemmings are wrong doesn't make them right.  Read the
> paper; it explains very well how recursive makefiles defeat dependency
> management completely.  This is the cause for the biggest and most
> insidious problems.

I have read them in a count that is inappropriate for the moment, many  
papers expressing novice opinion about danger of any thing, similar to  
warnings about smoking and fugu fish eating. None of them are good,  
because make (fish, smoke) still exist and widely used and happily  
consumed. And used mush more widely than Ada or Java.

If someone fills that people in danger with that tool, please be so kind  
to correct existing or to write a better tool, which is the right way, but  
as for me I am sick and tired from advices about devil things (like  
ada.calendar.time), those came from personal desire, and produce only  
warring about a need (a requirement!) of restrictive use, without  
constructive movement forward.

>> Why to name a good time-proven tool as devil? I see no reason, only
>> tendentious and imperatively expressed opinion.
>
> Make and especially recursive make have been time-proven to be fragile,
> unmaintainable, error-prone and inefficient.

Do you plan to rewrite all these old good debian packages?

> It is possible and recommended to
> use make the same way, i.e. by means of include Makefiles instead of
> recursive.

You can suppose here that make can include not complete makefiles but  
dependency info collected by a separate tool.

> This is a valid point.  The problem is that Make doesn't know about
> dependencies between Ada units like gnatmake does; therefore Make
> violates the Ada Reference manual.  In short, when compiling Ada you
> *must* use gnatmake or its equivalent for another compiler than GNAT.
> And yo *must* use whatever configuration file is appropriate for
> gnatmake.

*must* should better sounds with *can*, since this approach relates to  
GNAT only. And as a consequence the GNAT compilation model approach can  
not turn makefile into a devil thing. This is the same as personal haircut  
can not turn outer world into an ambiguous state.

> Ada has none of these deficiencies.
>
>> For Ada with gnat these are not appropriate enough of course, but it
>> is not due to recursively calling make, or autotools by itself. They
>> are just other tools for doing another things, and nothing
>> else. Regarding autotools and ada, take a look at AWS source - I dont
>> know why but you still need to 'configure' it. Would you like to know
>> why?
>
> I know why.  The configure in AWS is not constructed with autoconf, it
> is written by hand and is minimalistic.  The things that need
> configuring are: whether or not to support SSL or GNU TLS,
> etc. i.e. which libraries other than AWS are present on the system and
> should be used.  And AWS does not use automake either.

So here we can see when "none of these deficiencies" becomes a need to  
establish environment capabilities in "tls/ssl and etc" dependencies. So  
the correct answer here is that GNAT Ada has some deficiencies but in  
general they are different from C approach.

And no devil, indeed.
-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/