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,6df3ec0dff30c185 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!newsfeed.straub-nv.de!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Open source Ada OS? Date: Thu, 27 Jan 2011 16:29:26 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <4d3f3be3$0$22088$742ec2ed@news.sonic.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1296167369 22946 69.95.181.76 (27 Jan 2011 22:29:29 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 27 Jan 2011 22:29:29 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-RFC2646: Format=Flowed; Original Xref: g2news1.google.com comp.lang.ada:16753 Date: 2011-01-27T16:29:26-06:00 List-Id: That's surely part of it. But I think it really needs some mechanism to keep the common parts of files in synch without much manual intervention. That seems to be a tough problem; C systems often use macros and conditional compilation to deal with this, but that leads to a mess of hard to maintain code. Ada uses separate bodies instead, which is generally better. But it has the problem that if the specification changes, you have to manually change the matching specifications in all of the bodies in the same way. And this is just busywork; while you still need to inspect the actual body code, the specifications are pain. Similarly, in those "unshared" bodies, it is common that there is a routine or three that are the same for most (or even all) of those bodies; changing those more than once is a pain. I suspect that a scheme using structured comments would do the trick, but clearly such a system has to be Ada-aware (more generally, aware of the source language). Even better would be a GUI that was aware of that and automatically made the changes to parts of files, assembling the entire file only in the GUI, for export, and for compilation. But I worry that the result would be too complex for most mortals to use. Randy. "Edward Fish" wrote in message news:a8e001b7-254a-4143-b86a-2c38bbd50327@y9g2000prf.googlegroups.com... > Randy, > It sounds almost like you want the ability to: > a) Define a collection of files; (not a true set, as duplicate > [names] might be in it) > b) Have the ability to 'subset' this collection; (this would be your > [sub-]project) > c) Associate from the set in 'b' files from 'a'; (allowing different > bodies to be in different projects) > d) Have changes to some files {the bodies} update only their > associated file from 'a'. > > Something like this psudo-ada: > x86_Compiler : Project:= > ( "Compiler.A*","Frontend.A*","Backend.ADS","Backend.ADB" => "[INTEL]- > Backend.ADB" ); > > Is this an accurate description of what you want?