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,6458d1ee91b224ec X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.106.73 with SMTP id gs9mr2381753wib.2.1361849692059; Mon, 25 Feb 2013 19:34:52 -0800 (PST) MIME-Version: 1.0 Path: bp2ni59452wib.1!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.teledata-fn.de!weretis.net!feeder4.news.weretis.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: chopping Ada source that have preprocessor symbols in them Date: Mon, 18 Feb 2013 17:18:52 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <5111a9d5$0$6567$9b4e6d93@newsspool3.arcor-online.net><85txpnm1vp.fsf@stephe-leake.org><5114fb61$0$6561$9b4e6d93@newsspool4.arcor-online.net><85ehgqkxnf.fsf@stephe-leake.org><51168e7e$0$6566$9b4e6d93@newsspool3.arcor-online.net><85r4khdfm3.fsf@stephe-leake.org><511e17c3$0$9520$9b4e6d93@newsspool1.arcor-online.net><511E64AB.8030805@obry.net> <871ucffhtu.fsf@adaheads.sparre-andersen.dk> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1361229536 29143 69.95.181.76 (18 Feb 2013 23:18:56 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 18 Feb 2013 23:18:56 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-02-18T17:18:52-06:00 List-Id: "Jacob Sparre Andersen" wrote in message news:871ucffhtu.fsf@adaheads.sparre-andersen.dk... > Randy Brukardt wrote: > >> (And the use of a preprocessor is always suboptimal. It's much better >> to have that managed as part of version control, by selecting files >> specifically for particular targets -- but I've never seen a version >> control system that does that properly -- they all assume the use of >> preprocessors. For RRS, I built a front-end that adds such structure >> to the versioning (CVS is the back-end), but it's pretty clunky and >> never was turned into a product.) > > How would you do that in version control? You keep the relationships between related-but-different files. I don't know of any version control that can really do that. Also, you ought to be able to extract an entire buildable product from the version control with a single command; if you can do that (and have an appropriate build mechanism), you don't really need any other management technique (i.e. GPR files). > Personally I like the style used with the GNAT project files, where you > select different implementation variants with a parameter to the build > system. That covers the problem of finding the varied source files, but doesn't solve the problem of keeping them in synch. The former problem is easy, the latter is hard (and critical). > I guess you would like to be able to select a "branch" with a specific > implementation variant _and_ at the same time select a (different) > "branch" of all the invariant parts of the system. > > Now that I think about it, you could do that by having a subrepository > containing the implementation variants in different branches. Branching (as I've seen it implemented) really does not help. There are three kinds of files in a typical system. Consider the Janus/Ada compiler and a modernized example of reality. There needs to be code generated for Intel 32-bit and 64-bit targets, as well as ARM targets. And Windows and Linux. Most of the files of the compiler don't depend on the host or target at all, or only depend on them indirectly through descriptor packages. Some files (like part of an ARM code generator) don't appear in any other compiler version at all. So a mechanism like the GPR files would work fine for those. But other files have varied versions for different targets. The "weak" version of that is where the specification is shared and the bodies are unrelated. GPRs will help you with that, but you have a problem if you need to add a new item to the specification -- how do you find all of the bodies that need changes? But the real situation is that you have different but related versions for different targets. For instance, the host descriptor packages contain a large bunch of constants, some of which vary by target. What you don't want to do is have completely separate copies of these packages, because it makes changing one of the packages to add or delete something difficult -- now you have to change a bunch of other packages as well. Moreover, those bodies that are different for a shared body rarely are 100% custom for each target. Typically, the algorithms are similar in each target (and certainly the declarations are), and these shared parts really ought to be shared (so that if a modification needs to be made in one to fix a bug, it will get fixed in all versions). I suppose one could build something on top of an existing version control system (after all, this is what we tried to do back in the early 1990s). And it probably would have resemblance to a reversible preprocessor. Probably it would have to be built into an IDE. The trick would be for the IDE to manage the branching and making the changes to the appropriate parts of the source file so that the common parts get updated for all versions and the not common parts are only changed in one version. The problem is figuring out an appropriate user-interface for this; I never cracked that nut, and the whole idea doesn't work if it can't be done so people understand it. (Otherwise it just is another only-for-me program.) Randy.