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 Received: by 10.68.46.193 with SMTP id x1mr21248393pbm.7.1318772584931; Sun, 16 Oct 2011 06:43:04 -0700 (PDT) Path: d5ni16513pbc.0!nntp.google.com!news2.google.com!goblin3!goblin1!goblin.stu.neva.ru!feeder.news-service.com!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: Sun, 16 Oct 2011 15:43:03 +0200 Organization: cbb software GmbH Message-ID: 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> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: NkTZyZQzt+uRNthfI6+Hjg.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:13977 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: 2011-10-16T15:43:03+02:00 List-Id: On Sun, 16 Oct 2011 08:51:14 -0400, Stephen Leake wrote: > "Dmitry A. Kazakov" writes: > >> On Fri, 14 Oct 2011 00:25:15 +0200, Yannick Duch�ne (Hibou57) wrote: >> >>> Le Thu, 13 Oct 2011 16:18:27 +0200, Ludovic Brenta >>> a �crit: >>>> Directories are *not* a solution for these problems. They do not >>>> represent dependencies or hide any information from the compiler. >>> This is not a matter of semantic, this is a matter of being handy for >>> human beings. >> >> Actually long file names is not the problem. The problem is that GPS in its >> tree view control used for browsing the project units ignores the packages >> hierarchy in favor of the hierarchy of the file system. Change that in GPS >> (or another Ada IDE) and the problem would largely disappear. > > I still don't understand what "problem" is being solved here. Long file names, which are difficult to read. GPS project view shows file names, e.g.: gtk-layered-waveform-ring_data_buffer.adb gtk-layered-waveform-ring_data_buffer.ads It should rather show simple names of Ada units, e.g.: gtk |-layered | |-waveform | | |-ring_data_buffer | | | |-package specification | | | |-package body > A file system browser allows viewing files by file name; that's a good > solution for a class of problems. A package browser allows browsing > packages by package name; that's a good solution for another class of > problems. > > If the file and package names are the same, then you can use a file > browser as a package browser, avoiding the work of maintaining two > tools. > > When do file names and package names _need_ to be different? Always. Actually this is what the OP wished to have: a correspondence between fully qualified names of Ada units and paths of the files containing these units. Parent's name <-> directory name. Child name <-> file name. > I don't see any problem with long file names; they used to be a problem > on 80 character terminals, but we are past that now. For projects of many hundred files, it is a huge problem. Especially when you have hundreds of generic package instances popping everywhere. Pushing files into different directories makes things only worse. The point is, when browsing a project you are not interested in files, you are looking for Ada units, and it is absolutely irrelevant what is the file name of that unit. In fact, if the source control systems were not so retarded, we would have no files at all, just versions of units stored in a database. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de