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 gs9mr2379070wib.2.1361849356872; Mon, 25 Feb 2013 19:29:16 -0800 (PST) Path: bp2ni59445wib.1!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!216.196.110.142.MISMATCH!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!border4.nntp.ams.giganews.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: Jacob Sparre Andersen Newsgroups: comp.lang.ada Subject: Version control and multiple implementation variants (Was: chopping Ada source that have preprocessor symbols in them) Date: Tue, 19 Feb 2013 11:05:01 +0100 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: <87liakk4aa.fsf_-_@adaheads.sparre-andersen.dk> 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: monowall.adaheads.com Mime-Version: 1.0 X-Trace: munin.nbi.dk 1361269328 17880 77.234.168.91 (19 Feb 2013 10:22:08 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 19 Feb 2013 10:22:08 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:SwSqKkLpv5HwcrbjiKvc+NJKY7A= Content-Type: text/plain; charset=us-ascii Date: 2013-02-19T11:05:01+01:00 List-Id: Randy Brukardt wrote: > Jacob Sparre Andersen wrote: >> Randy Brukardt wrote: > 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). True. I've looked a little bit at Mercurial and its "subrepos" facility (http://mercurial.selenic.com/wiki/Subrepository). I think it (combined with a sensible use of separate bodies) does the trick. Taking Janus/Ada with two OS targets and two CPU architectures, you would set up a structure like this: Janus_Ada/ - thin build management repository Common/ - subrepo containing source files common to all targets OS_Specific/ - subrepo containing branches for Linux/Windows CPU_Specific/ - subrepo containing branches for ARM/Intel When you commit in the thin master repository, it will register which revision each of the subrepos are in, such that when you later check that revision out, the appropriate revisions will also be checked out in the subrepos. Commits in the master repository are aborted when there are uncommitted changes in subrepos. This will help assuring that a test-build actually matches what is committed in the build management repository. (Warning: Not tested.) > 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. These files are the ones I would put in "Common" in the example above. > 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. Yes. In the example above, I would commit these files in the "ARM" branch of "CPU_Specific". > 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? I think I would check the GPR "Naming" package for the list of implementation variants. In the example above I would have to check out (select) each branch in the relevant subrepo to see and change that body. > 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. Wouldn't this be doable with nested packages with separate bodies for the target specific parts? > 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). Yes. I think this is an example where it would make sense to use nested packages with separate bodies for the target specific parts. (But I have never written an Ada compiler, so I may be wrong.) > 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. With Mercurial and subrepos the IDE can basically run "hg branches" in each subrepo to get a list of possible settings, turning it into a drop-down list in the user interface. > 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.) I hope the ideas above are useful. Greetings, Jacob PS: When will you start accepting pre-orders for a Linux version of Janus/Ada? -- "In school, and in most aspects of life, a 90% is an A. In software, a 99.9% is, or may be, an utter disaster."