hp2ps depends on "ghcautoconf.h" and "ghcplatform.h", but does not yet need it. about hadrian

[snowleopard]

I have a bad feeling about this.

What happens is:

• We run clang -MM to compute dependencies of file hp2ps/Utilities.c
• It includes hp2ps/Main.h
• The latter includes generated file includes/ghcconfig.h
• But the file has not yet been generated, so clang -MM doesn't know what to do: what if includes/ghcconfig.h includes something else? We need to have it in order to determine accurate dependencies. So, clang -MM gives up! I wonder if gcc -MM gives up as well (I haven't seen this failure yet).

Not sure what's the best way to proceed with this. I can add a manual dependency: need includes files before running other rules, but this is fragile.

[snowleopard]

@ndmitchell Have you got any idea on how to handle this nicely? I don't have anything except for needing generated files explicitly.

[snowleopard]

I've added explicit dependencies. We may come back to this issue if a better approach is discovered.

[Ericson2314]

Hi, I've been lurkingfollowing along until I can get my computer replaced and actually contribute, but I think I have a solution for this.

Unfortunately, the non-lexical way CPP works makes things more complicated in that macros defined in headers included earlier influence the dependencies of headers included later.

I propse adding at the back of the INCLUDE path a directory with empty files named for each generated file (hopefully we can figure out that list up front). Then, when clang outputs a dependency on one of those stubs, we know we need to rebuilt it. Because of the aforemtioned non-lexicallity, after building all generated header files, we repeated the process. After a finite number of rounds, all relevant header files will be discovered and built (we'll know because clang will no longer fall back on the stubs).

[snowleopard]

@Ericson2314 Hi there! Adding a directory with fake files is a nice trick. I don't see how it helps though: we still need to explicitly list these files somewhere: we list them as dependencies in src/Rules/Dependencies.hs and everything seems to work well. You propose to list them in a special directory, and furthermore also run clang -MM a number of rounds, which would be hard to implement.

[ndmitchell]

One quite easy solution is to orderOnly depend on those files before running -MM. That ensures the files exists, but doesn't depend on them, and then -MM can spot them properly. The advantage of orderOnly is you can be much more free with it as it will reduce parallelism by a very tiny amount, but won't cause unnecessary rebuilds.

[snowleopard]

@ndmitchell Thanks! I didn't think of order-only dependencies. Looking at the Shake documentation this is exactly the intended use case for orderOnly.

(In an ideal world we would have a dependency discovery mechanism that would call orderOnly [file] whenever it encounters an include file statement while traversing given source files, so we wouldn't have to list such dependencies manually.)

[Ericson2314]

In an ideal world...

Well, in general CPP variables can be used in the #include path, so that won't work.

However, intercepting file access, as proposed in that linked issue, is the best of all worlds. Dirt simple, no up-front lists, and builds only the headers that are needed.