Re: problems with $(eval include...)

[Fabio Alemagna]

On Fri, 27 Jun 2003, Paul D. Smith wrote:
>   fa> automake uses recursive makefiles, which is something I want to
>   fa> avoid.
>
> I wasn't suggesting automake in total, I was suggesting their dependency
> generation style only... this is basically what's described on my
> website.

hum... I must have got something wrong, then... Please, clarify this: does
that method allow for proper handling of autogenerated files AND the usage
of one single big makefile as opposed to multiple recursive makefiles?

>   fa> exe: exe-deps obj1.o obj2.o obj3.o
>
>   fa> exe-deps:
>   fa>         $(eval -include obj1.d obj2.d obj3.d)
>
> This is not reliable.
>
> The instant you want to start allowing parallel builds, which are
> critical for today's software builds and for taking full advantage of
> today's hardware, your method is no longer guaranteed to work.

Isn't there any way to tell make to build exe-deps before any of the other
prerequisites of exe, even with -jn, n > 1? I think there should be one,
if there's not.

> I thought you sent me an email saying that using the CVS source, it
> worked?

It works only in some situations, whilst in others it segfaults. I'm not
quite sure which are those situations yet. I have to investigate further.
There's one common behaviour, though: in any case, even if there's no
segfault, if the file doesn't exist make doesn't invoke the rule to
generate it, as it should instead do.

>   fa> I'm going away from that way of doing dependencies, I certainly
>   fa> don't want to go back to it. Anyway, I'm pointing out a bug which
>   fa> needs to be solved anyway.
>
> I agree the core dump needs to be solved (if it's not already in CVS).
>
> However, I'm not so sure I agree that the method your using would be
> supported.  I don't know that it wouldn't be, but I'm not at all
> prepared to say right now that using $(eval ...) inside a command script
> to enhance or modify make's internal dependency graph by adding more
> prerequisites, would work.
>
> Make carries a lot of internal state during its walk of the dependency
> graph, like where it is, what it's looking for, etc., and if you go
> modifying the structure of that graph while make is in the middle of
> resolving it I can't say for sure that everything will work properly.

Yeah, I had that same concern, so I tried to check whether it worked, and
to my surprise it worked. But later on I discovered that it didn't work as
expected and didn't ALWAYS work, leading to segfaults. I suspect these
segfaults and the general malfunctioning are due to the fact that make
doesn't take into consideration that such an $(eval) construct might be
used that way. I'm sure I hit an "hidden" and not foreseen feature of
$(eval), which should be supported though, so to be consistent with the
general $(eval) semantics.

Fabio Alemagna