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 15:05:35 +0400:

> Vasiliy Molostov wrote on comp.lang.ada:
> Don't you see how wrong this approach is?

Perhaps it is not ideal, but exists.

> Add to that that Make dependencies do not take compiler flags into  
> account
> (gnatmake does) and are therefore incomplete.  For example:
>
> all: foo
> foo: a.o b.o
>         gcc -o $@ $<
>
> is not good enough, even when supplemented by generated source
> dependencies. Why? Because when CFLAGS contains -O3 or some explicit
> option, cross-unit inlining comes into the picture, so a.o does not  
> depend
> on "just" b.o, it depends on a b.o compiled with the *same compiler
> options*.  Make simply does not capture this dependency information.

YOu can place compiler options into a separate dependant file.

>> 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
>
> Correcting make is impossible without breaking compatibility with  
> existing
> makefiles.

Wooo. Indeed.

>  Therefore the only option is to replace make completely.
> gnatmake and gprbuild exist for this very purpose; so do all of the make
> alternatives mentioned elsewhere in this thread.

Do you plan to replace it completely?

> The constructive movement forward is: use *existing* better tools.
> If you still *must* use make, do that non-recursively.

*can*. The choice is mine, not your.

> No. I have *already* written all my Debian packages non-recursively
> and I routinely bypass upstream's fragile recursive makefiles with
> one non-recursive, simple makefile and one GNAT project file.  And
> I usually specify .SUFFIXES in most of my Makefiles because the
> predefined rules just get in the way.

And it is good, any approach applicable, by the choice.

> No.  This approach exists with all Ada compilers and with several other
> languages that mandate the precise tracking of dependencies between
> compilation units like OCaml and, to a lesser extent, Java.

I remember an *.alb file with compiler library level output collected in  
one file, which does not affect make tools too much.

> No.  While a personal haircut creates no danger, recursive makefiles do
> create danger.

If you are in danger it is not a recipe for any other people. I like my  
haircut, want to and
will follow rules I specify by my own experience, without unconditionally  
accepting things that
restricts a freedom of choice.

> No. The reason for the existence of "configure" in AWS is because the
> external, optional dependencies are not written in Ada.

You tend to say that this issue is internal tls/ssl problem that they are  
dependencies to AWS? I suppose that this is an AWS issue to refer these  
dependencies and a lack of appropriate tool to examine these dependencies  
without 'configure' related things, that came from autotools.

> In the Debian
> package for AWS, I bypass configure and upstream's makefile completely.
> Instead I use one non-recursive Makefile and one GNAT project file, as
> usual.  This is fast and reliable.

Also, a good approach, and it is a matter of choice.

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