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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c6567772e9f3871d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.8.135 with SMTP id r7mr6994084pba.8.1319028392185; Wed, 19 Oct 2011 05:46:32 -0700 (PDT) Path: d5ni31989pbc.0!nntp.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!news2.euro.net!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: organizing deep source trees with child packages Date: Wed, 19 Oct 2011 14:46:58 +0200 Organization: cbb software GmbH Message-ID: <1lffhk7bfsll5$.1mon42jbwt1yf$.dlg@40tude.net> References: <21c9e6bb-f4f7-4a00-bde7-68f2c1a42d01@q13g2000vby.googlegroups.com> <82ty7d1ewz.fsf@stephe-leake.org> <3486b228-abdd-490f-b4ef-9ee6b19f65fa@gy7g2000vbb.googlegroups.com> <7179717a-9837-476c-b564-6599a9c02acd@ff5g2000vbb.googlegroups.com> <1qk4l4n9zsdgm$.1bvxdhoq5cpx5.dlg@40tude.net> <82hb39umkd.fsf@stephe-leake.org> <82botev9j0.fsf@stephe-leake.org> <82ipnlu4to.fsf@stephe-leake.org> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news2.google.com comp.lang.ada:14087 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2011-10-19T14:46:58+02:00 List-Id: On Wed, 19 Oct 2011 02:52:50 -0700 (PDT), Ludovic Brenta wrote: > Placing all of your source files in one, or a few, directories > will not solve the problem either, but at least it will not make it > worse. There is a case when you need directories, that is OS/Debugging support. Usually I have files with the same names containing OS-dependent implementations selected by a GPR scenario variable. >>> I vote for the gnat convention, because the mapping is trivial, and >>> directories are a pain. >> >> Yes, they are when the tools are feeble. With proper tools you would not >> care. > > But you will always have to use a feeble tool at one point or > another. Think of version control systems, backup systems, pretty- > printers, find+grep, etc. which do not know, or want to know, about > file naming conventions or the semantics of Ada. What the use of them then? Except for backup which stores the whole file system anyway, the version control system must know Ada in order to build release versions, build and run automatic tests. The pretty printer must know it to be pretty, grep (or some more decent thing) must know Ada in order to search Ada sources by contents. >> Now that was just a trivial example for which some naming schema could >> easily be deployed in order to help with that. I am talking about projects >> which *do* use generics, of multiple generic parameters, child generic >> units etc. > > A file naming scheme does not help with generic instantiations because > some generic instantiations are nested in other units and therefore > not in a file of their own. Right, that is why IDE must know Ada. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de