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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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.33.210 with SMTP id i18mr1942352qad.4.1343910200048; Thu, 02 Aug 2012 05:23:20 -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!nntp.giganews.com!novia!feeder3.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.131.MISMATCH!xlned.com!feeder3.xlned.com!news.astraweb.com!border5.a.newsrouter.astraweb.com!goblin3!goblin.stu.neva.ru!news.matabio.net!jeffrey.matabio.net!thue.elzevir.fr!news.davenulle.org!gegeweb.org!aioe.org!.POSTED!not-for-mail From: "Vasiliy Molostov" 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 16:16:52 +0400 Organization: None Message-ID: References: <214bbd15-f7cb-4710-a6a7-64f37923bf4e@googlegroups.com> <87wr1moexq.fsf@ludovic-brenta.org> <87sjcaoa08.fsf@ludovic-brenta.org> <87k3xlbvkz.fsf@ludovic-brenta.org> <0ddccceb-c5ef-408a-b336-7cd2cd272ff8@googlegroups.com> NNTP-Posting-Host: Xw13RWgh8yxgPSv0x3+H9w.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.00 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 X-Received-Bytes: 5297 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable Date: 2012-07-30T16:16:52+04:00 List-Id: 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, = 30 Jul 2012 15:05:35 +0400: > Vasiliy Molostov wrote on comp.lang.ada: > Don't you see how wrong this approach is? Perhaps it is not ideal, but exists. > 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. YOu can place compiler options into a separate dependant file. >> If someone fills that people in danger with that tool, please be so k= ind >> to correct existing or to write a better tool, which is the right way= , = >> but > > Correcting make is impossible without breaking compatibility with = > existing > makefiles. Wooo. Indeed. > Therefore the only option is to replace make completely. > gnatmake and gprbuild exist for this very purpose; so do all of the ma= ke > alternatives mentioned elsewhere in this thread. Do you plan to replace it completely? > The constructive movement forward is: use *existing* better tools. > If you still *must* use make, do that non-recursively. *can*. The choice is mine, not your. > 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. And it is good, any approach applicable, by the choice. > No. This approach exists with all Ada compilers and with several othe= r > languages that mandate the precise tracking of dependencies between > compilation units like OCaml and, to a lesser extent, Java. I remember an *.alb file with compiler library level output collected in= = one file, which does not affect make tools too much. > No. While a personal haircut creates no danger, recursive makefiles d= o > create danger. If you are in danger it is not a recipe for any other people. I like my = = haircut, want to and will follow rules I specify by my own experience, without unconditionall= y = accepting things that restricts a freedom of choice. > No. The reason for the existence of "configure" in AWS is because the > external, optional dependencies are not written in Ada. You tend to say that this issue is internal tls/ssl problem that they ar= e = dependencies to AWS? I suppose that this is an AWS issue to refer these = = dependencies and a lack of appropriate tool to examine these dependencie= s = without 'configure' related things, that came from autotools. > 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. Also, a good approach, and it is a matter of choice. -- = =D0=9D=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE =D0=B2 =D0=BF=D0=BE=D1=87= =D1=82=D0=BE=D0=B2=D0=BE=D0=BC =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1=82=D0=B5= =D0=B1=D1=80=D0=B0=D1=83=D0=B7=D0=B5=D1=80=D0=B0 Opera: http://www.oper= a.com/mail/