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:a24:93:: with SMTP id 141mr5404015ita.17.1542826955960; Wed, 21 Nov 2018 11:02:35 -0800 (PST) X-Received: by 2002:aca:5395:: with SMTP id h143mr132542oib.6.1542826955707; Wed, 21 Nov 2018 11:02:35 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!news.muarf.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!q69no324731itb.0!news-out.google.com!v141ni100ita.0!nntp.google.com!q69no324728itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 21 Nov 2018 11:02:35 -0800 (PST) In-Reply-To: <1cc54d43-c7fb-420d-b7e7-6e447dec3f2d@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=31.186.239.209; posting-account=O1Kt4QoAAABKYAjrg-cGai_vZLnN2LEw NNTP-Posting-Host: 31.186.239.209 References: <0577e947-d691-4b81-aca6-b2e86bbef634@googlegroups.com> <04221674-95d8-4d4a-8743-42877b13eead@googlegroups.com> <7938d434-d666-4b80-a5cb-6c2f8ee70153@googlegroups.com> <1cc54d43-c7fb-420d-b7e7-6e447dec3f2d@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <63ec0eee-9ad8-49e9-9df5-667edc4c89af@googlegroups.com> Subject: Re: GNAT Modification_Time limitation From: Lionel Draghi Injection-Date: Wed, 21 Nov 2018 19:02:35 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:54867 Date: 2018-11-21T11:02:35-08:00 List-Id: Le mercredi 21 novembre 2018 08:40:08 UTC+1, briot.e...@gmail.com a =C3=A9c= rit=C2=A0: ... > With your idea of using ptrace, that would be an automatic way maybe to t= ell > redo about the dependency graph. Exactly, the idea of the POC is see how far we can go without any explicit = description of the dependency graph, or whatever build recipes. ... > A similar limitation seems to exist in your POC: how do I, as a novice us= er, > know what to compile in the first place ?=20 It's not in my scope : I don't target making easier compilations (I don't p= retend doing a better job than gprbuild or so), just running smartly a list= of command.=20 I used a C compilation exemple as it's a classical make exemple, but it cou= ld be whatever suite of command : latex .tex dvips .dvi ps2pdf .ps pdf2eps =20 And gprbuild, or even a complex make could be one those command. =20 ... > The ptrace approach would be much more reliable (though linux-specific), = since you would know > for instance: >=20 > - that the compiler searched and did not find foo,ads in /first/dir > - found and opened /other/dir/foo.ads >=20 > so next time there is a build you can check first whether 'foo.ads' now e= xists in /first/dir. If that file > now exists, you need to rebuild. Exactly my intent. And to build the dependency graph, I need to identify which file is an inpu= t file, and which one is an output (a target). To do so, I can either: 1. make a complex analysis of a detailed strace log file on each file opera= tion; 2. just ask strace the list of the involved files, and classify those file = thanks to modification time : if file modification time > execution time, t= hen it's an output.=20 The second option seems to be far less complex, but I need enough precision= in time stamps to discriminate if a file is older than the command run tim= e or not. Note also that I could store a hashtag for each used file to check if the f= ile is the same without getting in all those time tag problems (I am pretty= sure most OSes propose such services).=20 It would certainly be useful and reliable to decide re-executing a command,= but wouldn't help to classify if the used file was only read, or an output= .=20 So, I didn't investigate in that direction. -- Lionel