Re: GNAT Modification_Time limitation

[briot.emmanuel@gmail.com]

> @Emmanuel : my make is a POC to do a make without makefile! :-)
> it runs command and observes files accesses (thanks to linux kernel ptrace interface), and automatically understand what files it depends on, and what files are output.


There was an article earlier this week on reddit about `redo`, which seems to have a similar
idea of top-down compilation: you have a linker script that tells redo it needs a.o, b.o and c.o (then
redo recursively processes those), and finally does the link.
In turn, for a.o you would tell redo it needs a.ads, a.adb and b.ads, and then compile,...

With your idea of using ptrace, that would be an automatic way maybe to tell redo about the
dependency graph.

I am not sure redo would be really usable on actual projects though. You have to list the dependencies
for the linker for instance (I much prefer the gprbuild approach of finding those automatically).
A similar limitation seems to exist in your POC: how do I, as a novice user, know what to compile in
the first place ? It seems you would need a combination of what gprbuild does, with ptrace:

    - compile (with ptrace) the main unit.
    - gprbuild then uses the ALI file to find the dependencies, and check those recursively.
    - in your case, you would instead look at the ptrace output to find those dependencies.

The ptrace approach would be much more reliable (though linux-specific), since you would know
for instance:

    - that the compiler searched and did not find foo,ads in /first/dir
    - found and opened /other/dir/foo.ads

so next time there is a build you can check first whether 'foo.ads' now exists in /first/dir. If that file
now exists, you need to rebuild.
gprbuild doesn't handle such changes on the system, it only store what it found.

(this is all an interesting concept I learned this week from `redo`)

Let us know the result of the experiment !

Emmanuel