Re: chopping Ada source that have preprocessor symbols in them

["Randy Brukardt" <randy@rrsoftware.com>]

"Jacob Sparre Andersen" <sparre@nbi.dk> 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.