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

[Miles Bader <miles@gnu.org>]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
> Miles Bader wrote:
>>> However, I assume that this works only if the programmer properly used
>>> the appropriate .h files, which is in no way required by C.
>>
>> It assumes nothing about the way .h files are used.
>>
>> It essentially emits the include-file graph in an appropriate format,
>> usable by make.
>
> The hidden assumption here is that the -I flags and environment
> variables passed to the compiler to find the include files are the
> same when extracting the dependencies with -M and later when compiling
> using the extracted dependencies.

Sure, but that's not "the way .h files are used."

These days the compiler is usually only invoked once, using -M as an
additional option during the "real compile," which avoids the issue of
inconsistent invocation.  Each compile then essentially makes sure the
recorded dependency information is consistent with the object files.

[It's still of course possible to confuse things, e.g., by changing a
"-DFOO" option when FOO affects the include-graph, so some build
systems record the actual compiler options, and do a full recompile
whenever they change...]

Note that I'm not trying to say this is an elegant system -- it has
many obvious problems, and I think the "Ada way" is clearly better --
just that in practice, it often more or less, kinda-sorta, works.

It's well understood how clumsy all this is, and in the long run C++
will probably move more towards doing things like Ada does.  My
perception is that a real module system (supplanting include files) is
high on many people's agenda for the next C++ standard.

-miles

-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff