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

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

Robert A Duff <bobduff@shell01.theworld.com> писал(а) в своём письме Sun,  
29 Jul 2012 23:46:11 +0400:

> "Vasiliy Molostov" <molostoff@gmail.com> writes:
>
> Well, I don't see any need for "war" here. ;-)
> But anyway, I agree with Ludovic that recursive make
> causes a lot of trouble, and is best avoided.

I think that the problem is not in "recursive", but in the fact that GNAT  
produces objects in other way than usual gnu/gcc tools do, I mean that not  
every input ada (gnat ada) source file refers to the corresponding output  
object file, and thus breaks makefile "predefined rules" approach used  
with C or other gcc related stuff, where each input source file type  
corresponds to its output file type. And this cause dependency  
inconsistency (in terms usual to makefile related tools), and one of the  
issues here is well expressed by Ludovic in his debian-ada policy against  
ALI files problem.

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. Why to name a good time-proven tool as devil? I see no reason,  
only tendentious and imperatively expressed opinion.

> I can sympathize with the OP not wanting to learn about .gpr files
> for simple projects, but in that case, a simple 'make' file
> (non-recursive!) that invokes gnatmake can work well.
> If you can't figure out how to get gnatmake to put the executables
> where you want them, you can write some 'make' rules to copy them there.
>
>> It is well known that appropriate tool utilization can give appropriate
>> result, and vise versa.
>
> I'm not sure what you mean by "vice versa" in this case, but appropriate
> tool *choice* is also a good idea.

What I meant by vise versa: not well known tool utilization can give  
inappropriate
result, and vise versa.

> Learning about .gpr files isn't
> trivial, but it won't kill you.  And you might want to look at
> 'gprbuild', which can deal with multi-language projects -- .gpr
> is not just for Ada.

How about recursive gprbuild? How about distributed gprbuild?

>> Most open-source gnu c software are built using autotools with recursive
>> make use, and it is ok.
>
> I disagree that it is OK.

I doubt. I prefer makefiles in any kind, just because its widely used in  
unices, where most open-source software lives. Difficulty rises when  
someone comes with its own interface and tools, this makes things less  
compatible against environment. It is just an opinion, but I sure here is  
nothing devil or just anti-devil.

> In my experience, recursive make leads to
> complications and inefficiencies. For small projects, the
> inefficiencies might not matter, but I once converted a large
> project from recursive make to non-recursive, and went from
> over-10-hour builds to under-1-hour builds in the from-scratch
> case, and even better speedups in the incremental re-build case.

How much time spending postgres sources build, what do you think?
There are many recursive makefiles (at least up to 8.4) and I see no  
inefficiencies there. How about building it distributed across several  
hosts?

> Even for small projects, the difference between "few seconds" and
> "go get a cup of coffee" involves forgetting one's train
> of thought.

I doubt that makeing or building binaries can provide some possibility for  
thoughts about it. It is a final phase before 'make install'.

> As for autotools, I think they are a nightmare, and totally unnecessary
> for a language like Ada.  Gnat itself is built that way (because it's
> part of gcc), and it's nothing but trouble.

No. very good, while used appropriately, especially for C related stuff.
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?

> Hmm.  I don't know any good way to deal with ``"inter-goal" dependencies
> between subprojects'' via recursive 'make'.  Could you please outline
> your techniques?

I mean dependencies between subprojects (makefile "goals") defined for  
recursive make passes (directories with makefile, indeed), they become  
problematic when things depend on a subset of output files, not augmented  
in a component as a common standalone dependant unit and thus are not  
independent and atomic part of overall build process. This indeed can lead  
to an inconvenient problem of incomplete dependency "decomposition". But I  
suppose that this way make is used in unusual way as intermediate and  
temporary solution, so it can not be considered as devil. Just it can not  
handle all possible cases by itself, as every tool does - a hand and a  
head is required.

>  I don't much like 'make', but if I can learn some
> better 'make' techniques, that's a good thing, since I have to deal
> with it all the time!

It is better to get some large (old-school) open source tar-ball (I have  
learned it via compiling suse distribution sources under solaris,  
including gnat gcc jgnat and the rest of 4+Gb raw source code) and at the  
same time to read gnu makefile reference manual - after two-three days of  
"sick" reading any well-motivated person can find himself well-grounded to  
do anything with makefiles.

Also I think that debian is not good enough to learn usual "good"  
makefiles, since many debian package maintainers try to reach their  
package and subcomponent compatibility and do incorporating changes  
(patches and build instructions) that break build process defined by  
authors (this is a need, due to debian packaging and build bots  
environment, and is not a voluntary decision, but not always correct  
indeed). It is why better to get native tarball and all its dependencies,  
and it is why fsf gnat differs from debian gnat and from what we can get  
 from libre.adacore. Why these last four do not use the same gprbuild  
project file everywhere?

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