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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: AI12-0218: What is the portable representation clause for
 processing IETF packets on little-endian machines?
Date: Sat, 12 May 2018 14:08:04 +0100
Organization: A noiseless patient Spider
Message-ID: <lylgcphvij.fsf@pushface.org>
References: <ec0145a4-9698-41f2-bc70-964dc1850e50@googlegroups.com>
	<9af47760-e731-4cb5-a1a0-d63e31019ce5@googlegroups.com>
	<877eob1cc6.fsf@nightsong.com>
	<c9986056-cc3d-432b-839d-fa226eb6e5f8@googlegroups.com>
	<flk0a3Fpvi4U1@mid.individual.net>
	<5c9b9f90-884f-4de7-8663-d39a67949f4f@googlegroups.com>
	<pd54g5$k0o$2@franka.jacob-sparre.dk> <pd6ft7$m10$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org;
 posting-host="386cd22a5277e61cff5810e5bbe13a1a";
	logging-data="12333"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX184MPhych5CZM3DFldWQB4OWYEhWbCnnBk="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin)
Cancel-Lock: sha1:kZkUuNh8we5vXZm8Xe0I63eNN4U=
	sha1:bmHblijlkBV3HLhENKCYrmE29rM=
Xref: reader02.eternal-september.org comp.lang.ada:52314
Date: 2018-05-12T14:08:04+01:00
List-Id: <comp.lang.ada>

Björn Lundin <b.f.lundin@gmail.com> writes:

> On 2018-05-12 00:12, Randy Brukardt wrote:
>> 
>> The best way to do this in Ada is with different package bodies (and 
>> sometimes specs) for each target. 
>
> We do this too.
>
>> The problem is that existing version control systems cannot handle such 
>> designs properly. 
>
> To get around that we have subdirectories matching the target
>
> -w32_x86
> -lnx_x64
> -aix_ppc
>
> each of these directories would contain the native body and spec for the
> platform. Each directory and file is version_controlled.
>
> The build system (first homebrew, now gpr) only includes the directory
> matching the correct target. So when building on AIX, the compiler never
> sees the directories lnx_x64 not w32_x86.
>
> Each platform tests on an environment variable we set that has one of
> the above 3 values.
>
> So in essence we limit the files the compiler sees to the ones
> belonging to the current platform.

I have to say that my experience at Cortex GNAT RTS[1] is similar to
Randy's.

At the moment I have 6 usable branches; the gcc7* and gcc8* ones are
live:

   gcc6 (FSF GCC 6, GNAT GPL 2016)
   gcc7 (FSF GCC 7)
   gcc-finalization (FSF GCC 7 + finalization)
   gcc8 (FSF GCC 8)
   gcc-finalization (FSF GCC 8 + finalization)
   gnat-gpl-2017

The reason for the distinction is that the interface between the
compiler and the RTS changes; between gcc7 and gcc8 10 files changed,
and between gcc8 and gcc8-finalization 30 files changed (not including
tests).

The way I've "managed" this is to choose a branch to develop a change
on, implement the changes, commit, then checkout the other branch that
the development applies to and cherry-pick the commit(s) (i.e the
changes) from the first branch. This is error-prone, to say the
least. It'd be quite hard to do at all on my previously preferred DVCS,
Mercurial.

Your remarks about using directories for this are very interesting, I'll
be looking into them. I suspect the problem of "change a spec; apply
matching changes to all the variant package bodies" will remain, though.

[1] https://github.com/simonjwright/cortex-gnat-rts