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.66.86.6 with SMTP id l6mr1695796paz.1.1344321534739; Mon, 06 Aug 2012 23:38:54 -0700 (PDT) Path: g9ni2855643pbo.0!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!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!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 08:40:28 +0200 Organization: A noiseless patient Spider Message-ID: <87k3xlbvkz.fsf@ludovic-brenta.org> References: <214bbd15-f7cb-4710-a6a7-64f37923bf4e@googlegroups.com> <87wr1moexq.fsf@ludovic-brenta.org> <87sjcaoa08.fsf@ludovic-brenta.org> Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="21ebca96f67dd5c032955613b6f0e87a"; logging-data="6309"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Nx4puavjoEBFdeuBSL4Sj" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Cancel-Lock: sha1:sJFmywmVTNVJxh/HSGb2D4Oh3UM= sha1:veHqeslwbmjP8R3CRaa8NaPnJoY= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Date: 2012-07-30T08:40:28+02:00 List-Id: "Vasiliy Molostov" writes: > Robert A Duff писал(а) в своём письме > 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 > GNAT produces objects in other way than usual gnu/gcc tools do, I mean > that not every input ada (gnat ada) source file refers to the > corresponding output 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 against ALI files problem. No, even in C an object file corresponds to not one but *several* input files: one or possibly several *.c and many *.h files. Make was invented to compensate for the deficiencies of C, which does not track dependencies, and Make does a bad job of that, even in simple projects. > 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. Just because many lemmings are wrong doesn't make them right. Read the paper; it explains very well how recursive makefiles defeat dependency management completely. This is the cause for the biggest and most insidious problems. > Why to name a good time-proven tool as devil? I see no reason, only > tendentious and imperatively expressed opinion. Make and especially recursive make have been time-proven to be fragile, unmaintainable, error-prone and inefficient. > What I meant by vise versa: not well known tool utilization can give > inappropriate result, and vise versa. You are correct here. Using make recursively is *bad* use of make, only made by people who don't know make. And the results are, of course, inappropriate. > How about recursive gprbuild? How about distributed gprbuild? That doesn't exist. gprbuild doesn't call itself recursively. Instead, gnatmake and gprbuild read the entire closure of project files (within each other, including each other, extending each other) and processes this entire closure non-recursively. It is possible and recommended to use make the same way, i.e. by means of include Makefiles instead of recursive. > 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 is nothing devil or just anti-devil. This is a valid point. The problem is that Make doesn't know about 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. [about autotools] > No. very good, while used appropriately, especially for C related > stuff. Make was invented to compensate for the deficiencies of C with respect to dependency managament. Automake was invented to compensate for the deficiencies of Make with respect to maintenance of fragile and huge Makefiles (i.e. the inappropriate use of Make). Autoconf was invented to compensate for the deficiencies of Automake with respect to configuration management and of C with respect to portability, even across Unices. Ada has none of these deficiencies. > 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 and ada, take a look at AWS source - I dont > know why but you still need to 'configure' it. Would you like to know > why? I know why. The configure in AWS is not constructed with autoconf, it is written by hand and is minimalistic. The things that need configuring are: whether or not to support SSL or GNU TLS, etc. i.e. which libraries other than AWS are present on the system and should be used. And AWS does not use automake either. -- Ludovic Brenta.