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: border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: spec/body/rep (Was: Compilation error (GNAT bug?)) Date: Tue, 27 May 2014 09:22:16 +0300 Organization: Tidorum Ltd Message-ID: References: <537bd591$0$6621$9b4e6d93@newsspool4.arcor-online.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: individual.net dLID6m0+T4fv8ppz83+6iwGJBm3HWnIi9pL26+Bpan59ff/jTo Cancel-Lock: sha1:VCtIXBvudc3aI/dRfmFS9MN0UF8= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: X-Original-Bytes: 3438 Xref: number.nntp.dca.giganews.com comp.lang.ada:186639 Date: 2014-05-27T09:22:16+03:00 List-Id: 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... :-) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .