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!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: pragma/aspect Import, Convention parameters Date: Thu, 13 Aug 2015 15:32:23 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1439497944 22544 24.196.82.226 (13 Aug 2015 20:32:24 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 13 Aug 2015 20:32:24 +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 Xref: news.eternal-september.org comp.lang.ada:27443 Date: 2015-08-13T15:32:23-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net... > Why is it an identifier? Dunno. That's what Ada 95 defined, and we've never had a request to change it. In my experience (which is mostly with rather low-level stuff), there is a lot more different than just the convention when changing between Linux and Windows (subprogram names, parameter values, etc.) So it's not much of a hardship to use separate thin bindings for each -- the differences are reconciled in the thick binding anyway. The problem with such an approach is that conventional version control doesn't work very well with it; one needs to control individual blocks with some different and many being shared. Ideally, changes in shared parts would be reflected in all of the related versions of each package, while changes in the unshared parts would not. We never found a solution to this for Janus/Ada (which has this problem in many modules); we extracted some host and target dependencies into dedicated packages, but many of them are not so simple and need to be described in code. We ended up with a version control overlay which manages the relationships between the different versions, so that a change in one version would trigger a request to check if the other versions needed similar updates (they usually do). But that checking had to be done manually. We side-stepped the problem for Claw by not supporting any other targets than Windows. :-) It would have been a lot worse had we wanted to support (say) GTK on Linux. Randy.