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

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

Vasiliy Molostov wrote on comp.lang.ada:
> Ludovic Brenta <ludovic@ludovic-brenta.org> писал(а) в своём письме Mon,  
> 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.

Don't you see how wrong this approach is?
- The Makefile must call gcc -M to generate the dependencies and store
  them in a file
- The Makefile *cannot* include the generated dependency file while it
  runs
- therefore you must run make twice: (1) to generate the dependency info
  and (2) to build using the dependency info.

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.

> 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?

Yes.

> 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.  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.

> 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.

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

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

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.

BTW, many "old good Debian packages" are actually old and bad; this
is being revealed by the growing number of build failures triggered
by parallelism.  To the point where many "old good Debian packages",
rather than fixing or rewriting their recursive makefiles completely,
disable parallel builds altogether.

>> 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

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.
  
> not turn makefile into a devil thing. This is the same as personal haircut  
> can not turn outer world into an ambiguous state.

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

> 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.

No. The reason for the existence of "configure" in AWS is because the
external, optional dependencies are not written in Ada.  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.  And I don't need to call configure
because Debian allows me to control which external libraries must be
present before building AWS.

-- 
Ludovic Brenta.