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.66.76.38 with SMTP id h6mr1473358paw.15.1344323650474; Tue, 07 Aug 2012 00:14:10 -0700 (PDT) Path: p10ni3060212pbh.1!nntp.google.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!ctu-peer!news.nctu.edu.tw!goblin1!goblin2!goblin.stu.neva.ru!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 04:20:15 +0400 Organization: None Message-ID: References: <214bbd15-f7cb-4710-a6a7-64f37923bf4e@googlegroups.com> <87wr1moexq.fsf@ludovic-brenta.org> <87sjcaoa08.fsf@ludovic-brenta.org> 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 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable Date: 2012-07-30T04:20:15+04:00 List-Id: Robert A Duff =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 Sun, = 29 Jul 2012 23:46:11 +0400: > "Vasiliy Molostov" writes: > > Well, I don't see any need for "war" here. ;-) > But anyway, I agree with Ludovic that recursive make > causes a lot of trouble, and is best avoided. I think that the problem is not in "recursive", but in the fact that GNA= T = produces objects in other way than usual gnu/gcc tools do, I mean that n= ot = every input ada (gnat ada) source file refers to the corresponding outpu= t = object file, and thus breaks makefile "predefined rules" approach used = with C or other gcc related stuff, where each input source file type = corresponds to its output file type. And this cause dependency = inconsistency (in terms usual to makefile related tools), and one of the= = issues here is well expressed by Ludovic in his debian-ada policy agains= t = ALI files problem. But why the "recursive" is devil? Usual project contains many files that= = needs to be built, not only source code, but data, man pages and docs, = configurations, all these are separate and usually built via recursive = makefiles. Why to name a good time-proven tool as devil? I see no reason= , = only tendentious and imperatively expressed opinion. > I can sympathize with the OP not wanting to learn about .gpr files > for simple projects, but in that case, a simple 'make' file > (non-recursive!) that invokes gnatmake can work well. > If you can't figure out how to get gnatmake to put the executables > where you want them, you can write some 'make' rules to copy them ther= e. > >> It is well known that appropriate tool utilization can give appropria= te >> result, and vise versa. > > I'm not sure what you mean by "vice versa" in this case, but appropria= te > tool *choice* is also a good idea. What I meant by vise versa: not well known tool utilization can give = inappropriate result, and vise versa. > Learning about .gpr files isn't > trivial, but it won't kill you. And you might want to look at > 'gprbuild', which can deal with multi-language projects -- .gpr > is not just for Ada. How about recursive gprbuild? How about distributed gprbuild? >> Most open-source gnu c software are built using autotools with recurs= ive >> make use, and it is ok. > > I disagree that it is OK. I doubt. I prefer makefiles in any kind, just because its widely used in= = unices, where most open-source software lives. Difficulty rises when = someone comes with its own interface and tools, this makes things less = compatible against environment. It is just an opinion, but I sure here i= s = nothing devil or just anti-devil. > In my experience, recursive make leads to > complications and inefficiencies. For small projects, the > inefficiencies might not matter, but I once converted a large > project from recursive make to non-recursive, and went from > over-10-hour builds to under-1-hour builds in the from-scratch > case, and even better speedups in the incremental re-build case. How much time spending postgres sources build, what do you think? There are many recursive makefiles (at least up to 8.4) and I see no = inefficiencies there. How about building it distributed across several = hosts? > Even for small projects, the difference between "few seconds" and > "go get a cup of coffee" involves forgetting one's train > of thought. I doubt that makeing or building binaries can provide some possibility f= or = thoughts about it. It is a final phase before 'make install'. > As for autotools, I think they are a nightmare, and totally unnecessar= y > for a language like Ada. Gnat itself is built that way (because it's > part of gcc), and it's nothing but trouble. No. very good, while used appropriately, especially for C related stuff.= For Ada with gnat these are not appropriate enough of course, but it is = = not due to recursively calling make, or autotools by itself. They are just other = tools for doing another things, and nothing else. Regarding autotools an= d = ada, take a look at AWS source - I dont know why but you still need to = 'configure' it. Would you like to know why? > Hmm. I don't know any good way to deal with ``"inter-goal" dependenci= es > between subprojects'' via recursive 'make'. Could you please outline > your techniques? I mean dependencies between subprojects (makefile "goals") defined for = recursive make passes (directories with makefile, indeed), they become = problematic when things depend on a subset of output files, not augmente= d = in a component as a common standalone dependant unit and thus are not = independent and atomic part of overall build process. This indeed can le= ad = to an inconvenient problem of incomplete dependency "decomposition". But= I = suppose that this way make is used in unusual way as intermediate and = temporary solution, so it can not be considered as devil. Just it can no= t = handle all possible cases by itself, as every tool does - a hand and a = head is required. > I don't much like 'make', but if I can learn some > better 'make' techniques, that's a good thing, since I have to deal > with it all the time! It is better to get some large (old-school) open source tar-ball (I have= = learned it via compiling suse distribution sources under solaris, = including gnat gcc jgnat and the rest of 4+Gb raw source code) and at th= e = same time to read gnu makefile reference manual - after two-three days o= f = "sick" reading any well-motivated person can find himself well-grounded = to = do anything with makefiles. Also I think that debian is not good enough to learn usual "good" = makefiles, since many debian package maintainers try to reach their = package and subcomponent compatibility and do incorporating changes = (patches and build instructions) that break build process defined by = authors (this is a need, due to debian packaging and build bots = environment, and is not a voluntary decision, but not always correct = indeed). It is why better to get native tarball and all its dependencies= , = and it is why fsf gnat differs from debian gnat and from what we can get= = from libre.adacore. Why these last four do not use the same gprbuild = project file everywhere? -- = =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/