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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: spec/body/rep (Was: Compilation error (GNAT bug?)) Date: Tue, 27 May 2014 10:55:39 +0200 Organization: cbb software GmbH Message-ID: References: <537bd591$0$6621$9b4e6d93@newsspool4.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: QTaafVZuunHujkJPndFR7g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Path: border2.nntp.dca.giganews.com!nntp.giganews.com!news.bnb-lp.com!news.glorb.com!aioe.org!.POSTED!not-for-mail Xref: number.nntp.dca.giganews.com comp.lang.ada:186645 Date: 2014-05-27T10:55:39+02:00 List-Id: On Tue, 27 May 2014 09:22:16 +0300, Niklas Holsti wrote: > On 14-05-27 08:16 , J-P. Rosen wrote: >> Le 23/05/2014 23:21, Randy Brukardt a écrit : >>> I don't think so, mainly because you already have such a capability: >>> constants! It's not the presence or absence of an aspect that changes, it's >>> the value. So it might make sense to have a package specifically for the >>> target-specific details (many systems do that, including the ACATS). >>> >>> For instance: >>> package Target_Specific is >>> -- Package for Windows. >>> pragma Linker_Options (...); >>> >>> -- Data types: >>> type Largest_Integer is range -2**31 .. 2**31 with Size => 32; >>> type Largest_Modular is mod 2**32 with Size => 32; >>> >>> -- Interfacing details for package Blarch: >>> Foo_External_Name : constant String := "..."; >>> Bar_External_Name : constant String := "..."; >>> >>> ... >>> end Target_Specific; >>> >>> And then have separate versions of the package for the various targets >>> supported. >> And to ease porting, have a package called Target_Specific_Windows, >> another one called Target_Specific_Linux. All the users do: >> with Target_Specific; >> >> and have the following library-lever renaming: >> with Target_Specific_Windows; >> package Target_Specific renames Target_Specific_Windows; > > I don't see what advantage such as a library-level renaming gives. If > one is developing for several platforms, say Windows and Linux, there > will then be two library-level renamings somewhere, one as above and the > other using Target_Specific_Linux, but some compiler-specific way is > still needed to choose which of the library level renamings to include > in the compilation. So one could just as well call both the > target-specific packages Target_Specific, directly, and use the same > compiler-specific way to choose which one to compile. For example, I use > GNAT's ADA_INCLUDE_PATH to choose the folder ("linux" or "windows") > which contains the version of Target_Specific to be compiled. > > Would there be some sense in being able to specify such library-level > renamings as configuration pragmas? This might give us a standard way to > choose component versions depending on the configuration (leaving as > compiler-specific the way to select which configuration is to be > compiled... :-) I have issues with this approach in general. The problem is that there is no any check that the interfaces of the target-specific packages are same in the sense that all target-independent clients were compilable with any "implementation." In my projects I, of course, use neither pragmas nor renaming. It is too clumsy and unmaintainable. I simply put same named package into different target-specific directories, e.g. x86/windows or i686/linux and switch them using gpr scenario. This does not solve the abovementioned problem, though. As a possible solution, without introducing some huge stuff of formal package interfaces [*], it would be enough to be able to switch only the private part of the specification and the package body, keeping the public part same. It would not work with target-specific constants and conditionally with-ed packages. ----------------------- * Much needed for generic formal packages, though. But this is a different story. BTW, target-specific packages could be considered instances of some virtual generic package with target as an actual parameter. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de