Re: spec/body/rep (Was: Compilation error (GNAT bug?))

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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