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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,163994d4f34e92d0 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.180.95.2 with SMTP id dg2mr1191842wib.2.1344264100396; Mon, 06 Aug 2012 07:41:40 -0700 (PDT) Path: q11ni72632303wiw.1!nntp.google.com!feed-C.news.volia.net!volia.net!news2.volia.net!feed-A.news.volia.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.panservice.it!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Miles Bader Newsgroups: comp.lang.ada Subject: Re: how to tell gnatmake to send executables to a different directory when compiling multi source? Date: Thu, 02 Aug 2012 14:01:08 +0900 Message-ID: <874nolc2gb.fsf@catnip.gol.com> References: <214bbd15-f7cb-4710-a6a7-64f37923bf4e@googlegroups.com> <87wr1moexq.fsf@ludovic-brenta.org> <87sjcaoa08.fsf@ludovic-brenta.org> <50167d29$0$6570$9b4e6d93@newsspool4.arcor-online.net> <873947cbja.fsf@catnip.gol.com> <1ffdae87-74c9-4900-9645-bf1c5828e448@r9g2000yqr.googlegroups.com> Mime-Version: 1.0 X-Trace: individual.net r+f+1j/EdnO3J/kTFgg3TQ+OQML8Krfdjgu830h3mjcp/dNUbfEZWEWoP0/Ot6W6KN Cancel-Lock: sha1:rzw23AZ6CM7Pv1+ELUrmZ8Bvze8= sha1:vEnpDP1HOxHFWcDgoapyaYMc4Lw= System-Type: x86_64-unknown-linux-gnu Content-Type: text/plain Date: 2012-08-02T14:01:08+09:00 List-Id: Ludovic Brenta writes: > Miles Bader wrote: >>> However, I assume that this works only if the programmer properly used >>> the appropriate .h files, which is in no way required by C. >> >> It assumes nothing about the way .h files are used. >> >> It essentially emits the include-file graph in an appropriate format, >> usable by make. > > The hidden assumption here is that the -I flags and environment > variables passed to the compiler to find the include files are the > same when extracting the dependencies with -M and later when compiling > using the extracted dependencies. Sure, but that's not "the way .h files are used." These days the compiler is usually only invoked once, using -M as an additional option during the "real compile," which avoids the issue of inconsistent invocation. Each compile then essentially makes sure the recorded dependency information is consistent with the object files. [It's still of course possible to confuse things, e.g., by changing a "-DFOO" option when FOO affects the include-graph, so some build systems record the actual compiler options, and do a full recompile whenever they change...] Note that I'm not trying to say this is an elegant system -- it has many obvious problems, and I think the "Ada way" is clearly better -- just that in practice, it often more or less, kinda-sorta, works. It's well understood how clumsy all this is, and in the long run C++ will probably move more towards doing things like Ada does. My perception is that a real module system (supplanting include files) is high on many people's agenda for the next C++ standard. -miles -- I'm beginning to think that life is just one long Yoko Ono album; no rhyme or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff