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,UTF8 Received: by 10.224.100.137 with SMTP id y9mr13804430qan.2.1343909994477; Thu, 02 Aug 2012 05:19:54 -0700 (PDT) Path: a15ni4867845qag.0!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.138.MISMATCH!xlned.com!feeder5.xlned.com!feed.xsnews.nl!border-1.ams.xsnews.nl!goblin3!goblin.stu.neva.ru!news.matabio.net!jeffrey.matabio.net!thue.elzevir.fr!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!74.125.178.16.MISMATCH!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: how to tell gnatmake to send executables to a different directory when compiling multi source? Date: Mon, 30 Jul 2012 04:05:35 -0700 (PDT) Organization: http://groups.google.com Message-ID: <0ddccceb-c5ef-408a-b336-7cd2cd272ff8@googlegroups.com> References: <214bbd15-f7cb-4710-a6a7-64f37923bf4e@googlegroups.com> <87wr1moexq.fsf@ludovic-brenta.org> <87sjcaoa08.fsf@ludovic-brenta.org> <87k3xlbvkz.fsf@ludovic-brenta.org> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 X-Trace: posting.google.com 1343646667 20964 127.0.0.1 (30 Jul 2012 11:11:07 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 30 Jul 2012 11:11:07 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-Received-Bytes: 6996 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: 2012-07-30T04:05:35-07:00 List-Id: Vasiliy Molostov wrote on comp.lang.ada: > Ludovic Brenta =D0=BF=D0=B8=D1=81=D0=B0=D0= =BB(=D0=B0) =D0=B2 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D0=BF=D0=B8=D1=81=D1=8C= =D0=BC=D0=B5 Mon, =20 > As we can see from predefined make rules >=20 > %.o: %.c >=20 > which means that C input source file has a direct correspondence to a =20 > resulting object file, and which is not applicable to gnat ada sources at= =20 > all. Make is a general tool supporting that strict input-output pairing = =20 > correspondence approach. >=20 > As for dependencies of C code and header files (*.h) they are come from = =20 > gcc autogenerated dependencies, lately included into makefile as a part. Don't you see how wrong this approach is? - The Makefile must call gcc -M to generate the dependencies and store them in a file - The Makefile *cannot* include the generated dependency file while it runs - therefore you must run make twice: (1) to generate the dependency info and (2) to build using the dependency info. Add to that that Make dependencies do not take compiler flags into account (gnatmake does) and are therefore incomplete. For example: all: foo foo: a.o b.o gcc -o $@ $< is not good enough, even when supplemented by generated source dependencies. Why? Because when CFLAGS contains -O3 or some explicit option, cross-unit inlining comes into the picture, so a.o does not depend on "just" b.o, it depends on a b.o compiled with the *same compiler options*. Make simply does not capture this dependency information. > The way it works is similar to all C stuff, someone has even named > it as dancing with a blade. Is it danger? Perhaps. Is it devil? Yes. > If someone fills that people in danger with that tool, please be so kind = =20 > to correct existing or to write a better tool, which is the right way, bu= t =20 Correcting make is impossible without breaking compatibility with existing makefiles. Therefore the only option is to replace make completely. gnatmake and gprbuild exist for this very purpose; so do all of the make alternatives mentioned elsewhere in this thread. > as for me I am sick and tired from advices about devil things (like =20 > ada.calendar.time), those came from personal desire, and produce only =20 > warring about a need (a requirement!) of restrictive use, without =20 > constructive movement forward. The constructive movement forward is: use *existing* better tools. If you still *must* use make, do that non-recursively. > Do you plan to rewrite all these old good debian packages? No. I have *already* written all my Debian packages non-recursively and I routinely bypass upstream's fragile recursive makefiles with one non-recursive, simple makefile and one GNAT project file. And I usually specify .SUFFIXES in most of my Makefiles because the predefined rules just get in the way. BTW, many "old good Debian packages" are actually old and bad; this is being revealed by the growing number of build failures triggered by parallelism. To the point where many "old good Debian packages", rather than fixing or rewriting their recursive makefiles completely, disable parallel builds altogether. >> dependencies between Ada units like gnatmake does; therefore Make >> violates the Ada Reference manual. In short, when compiling Ada you >> *must* use gnatmake or its equivalent for another compiler than GNAT. >> And yo *must* use whatever configuration file is appropriate for >> gnatmake. >=20 > *must* should better sounds with *can*, since this approach relates to = =20 > GNAT only. And as a consequence the GNAT compilation model approach can No. This approach exists with all Ada compilers and with several other languages that mandate the precise tracking of dependencies between compilation units like OCaml and, to a lesser extent, Java. =20 > not turn makefile into a devil thing. This is the same as personal haircu= t =20 > can not turn outer world into an ambiguous state. No. While a personal haircut creates no danger, recursive makefiles do create danger. > So here we can see when "none of these deficiencies" becomes a need to = =20 > establish environment capabilities in "tls/ssl and etc" dependencies. So = =20 > the correct answer here is that GNAT Ada has some deficiencies but in =20 > general they are different from C approach. No. The reason for the existence of "configure" in AWS is because the external, optional dependencies are not written in Ada. In the Debian package for AWS, I bypass configure and upstream's makefile completely. Instead I use one non-recursive Makefile and one GNAT project file, as usual. This is fast and reliable. And I don't need to call configure because Debian allows me to control which external libraries must be present before building AWS. --=20 Ludovic Brenta.