From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 2002:a02:4f03:: with SMTP id c3mr3688814jab.13.1542786007466;
        Tue, 20 Nov 2018 23:40:07 -0800 (PST)
X-Received: by 2002:a9d:2c22:: with SMTP id f31mr88792otb.4.1542786007164;
 Tue, 20 Nov 2018 23:40:07 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!z5-v6no121245ite.0!news-out.google.com!v141ni55ita.0!nntp.google.com!q69no120993itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 20 Nov 2018 23:40:06 -0800 (PST)
In-Reply-To: <7938d434-d666-4b80-a5cb-6c2f8ee70153@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=176.130.29.212;
 posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH
NNTP-Posting-Host: 176.130.29.212
References: <0577e947-d691-4b81-aca6-b2e86bbef634@googlegroups.com>
 <04221674-95d8-4d4a-8743-42877b13eead@googlegroups.com>
 <7938d434-d666-4b80-a5cb-6c2f8ee70153@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1cc54d43-c7fb-420d-b7e7-6e447dec3f2d@googlegroups.com>
Subject: Re: GNAT Modification_Time limitation
From: briot.emmanuel@gmail.com
Injection-Date: Wed, 21 Nov 2018 07:40:07 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader01.eternal-september.org comp.lang.ada:54854
Date: 2018-11-20T23:40:06-08:00
List-Id: <comp.lang.ada>

> @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