Pragma for conditional compilation? (Ada 2005 vs. 95)

Pragma for conditional compilation? (Ada 2005 vs. 95)

[Jerry]

Is there a pragma to designate some lines of Ada for conditional
compilation depending on if the compiler is Ada 2005 or not?

I have made some bindings that use some of the declarations from Annex
G.3 which relates to vector-matrix stuff which is new to Ada 2005. If
the compiler provides those declarations (i.e., is 2005), I want to
use the compiler's version because I figure that is the cleanest way
to get things done. If the compiler is Ada 95, I instead want to
provide the declarations myself.

Currently, I handle this by commenting out the declarations of my own
if Ada 2005 and uncomment them if Ada 95. (There are a couple of
"with" and "use" lines that also have to be (un)commented but it is a
similar situation.)

I'm guessing this is an Ada "no-no" but would be interested to know
for sure.

Jerry

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Georg Bauhaus]

On Thu, 2007-09-27 at 00:56 -0700, Jerry wrote:
> Is there a pragma to designate some lines of Ada for conditional
> compilation depending on if the compiler is Ada 2005 or not?
> 
> ... If
> the compiler provides those declarations (i.e., is 2005), I want to
> use the compiler's version because I figure that is the cleanest way
> to get things done. If the compiler is Ada 95, I instead want to
> provide the declarations myself.
> 
> Currently, I handle this by commenting out the declarations of my own
> if Ada 2005 and uncomment them if Ada 95. 

Sounds like simple configuration management will help.
If you are using GNAT, make two project files, and two
source directories for units that differ.
Import the proper files from your source code repository,
or select source directories using some make tool, ...


 -- Georg 

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Pascal Obry]

Georg Bauhaus a �crit :
> Sounds like simple configuration management will help.
> If you are using GNAT, make two project files, and two
> source directories for units that differ.

Or one project file with the proper directory selected by a project
variable. This variable will appear inside GPS (see scenario view).
Quite handy and very simple. But I agree, no conditional compilation
needed this is a configuration management issue.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Jerry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1293 bytes --]

On Sep 27, 9:59 am, Pascal Obry <pas...@obry.net> wrote:
> Georg Bauhaus a écrit :
>
> > Sounds like simple configuration management will help.
> > If you are using GNAT, make two project files, and two
> > source directories for units that differ.
>
> Or one project file with the proper directory selected by a project
> variable. This variable will appear inside GPS (see scenario view).
> Quite handy and very simple. But I agree, no conditional compilation
> needed this is a configuration management issue.
>
> Pascal.
>
Thanks all who suggested the project file solution. That sounds like
the way to go. More to learn for me 8^).

I would then have to see how this might fit into the build system
(cmake) used by the SVN gurus on this project. (The project is PLplot,
BTW.) They have been amazing in their ability to incorporate my Ada
code into their project so far, given that there are no Ada
programmers involved (except for me) and given that I know little of
cmake or SVN (commits are made for me by a guru).

The good news is that everything I have done compiles and runs
correctly on every system that they have tested it with (thanks to
help I received quite a while back from this list regarding other
issues).

Always the Ada noob,
Jerry

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Stephen Leake]

Jerry <lanceboyle@qwest.net> writes:

> Is there a pragma to designate some lines of Ada for conditional
> compilation depending on if the compiler is Ada 2005 or not?
>
> I have made some bindings that use some of the declarations from Annex
> G.3 which relates to vector-matrix stuff which is new to Ada 2005. If
> the compiler provides those declarations (i.e., is 2005), I want to
> use the compiler's version because I figure that is the cleanest way
> to get things done. If the compiler is Ada 95, I instead want to
> provide the declarations myself.
>
> Currently, I handle this by commenting out the declarations of my own
> if Ada 2005 and uncomment them if Ada 95. (There are a couple of
> "with" and "use" lines that also have to be (un)commented but it is a
> similar situation.)
>
> I'm guessing this is an Ada "no-no" but would be interested to know
> for sure.

There is no standard pragma that does this.

GNAT provides the gnatprep tool, which is a preprocessor, that could
do this.

A more portable way is to have to different source files, and use the
build tools to select the proper one. GNAT project files can do that.

-- 
-- Stephe

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Brian Drummond]

On Thu, 27 Sep 2007 00:56:09 -0700, Jerry <lanceboyle@qwest.net> wrote:

>Is there a pragma to designate some lines of Ada for conditional
>compilation depending on if the compiler is Ada 2005 or not?

I'm new to Ada though some of the concepts are familiar from VHDL...

There, one approach is to put the bindings in a package, and substitute
different package bodies according to the environment. Would that work
here?

- Brian

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[anon]

There is a "NON STANDARD" GNAT pragma. 

"conditional compilation" is undefined in the LRM or in Ada. A simple 
reason is Ada prevents intermix specification or packages by not allowing 
"conditional compilation". 

Note: Java is bad about allowing older specs routines to be compiled and 
used in newer java compiler. It does give an error message but it still 
compiles the code and will run with unpredictablity results.

Now all Ada compiling systems do address the issue of "conditional 
compilation" in there own way. And all accept the makefile type which is 
the best.

Now for Gnat:

First, is the tried and true version of using a OS script file or makefile 
to include the correct separate Ada packages. GNAT uses this in the 
source by having a number of packages that are the same package but 
for different OSs or CPUs. Such as "system-aix.ads", 
"system-freebsd-x86.ads", "system-linux-alpha.ads", 
"system-linux-x86.ads", "system-vms_64.ads" etc. This is the normal 
and best way if you planning to release the source code to the general 
public because you do not want to limit the users from compiling 
your software package. 

The second is to use the GNAT project with separate file structures. 
And in this version the project to chooses the file with a conditional 
switch in the command line.

In both previous design the code is straight foreward and prohibits
inserting and mixing the different specifications which can cause 
unpredictable behavior. In this case it all Ada 95, or all Ada 2005 
specs not both.

The third real old way is to code in the option by a "IF-THEN-ELSE-END" 
statements and use a Global constant variable(s). Its low tech but it 
still works.  GNAT uses this in the compiler. If you check the private 
section in the System package.  Those constants defines the default 
operations of the compiler. And example is the "OpenVMS" variable will 
to False unless it was compiled for OpenVMS. But you need to be careful 
that you call the correct routines. 

The next two ways are GNAT only. Even though other Ada system may 
have a similar ways.

The fourth, is to use "gnat preprocess" or "gnatprep" program. But 
you may have to rewrite the code if you use other Ada system.

The fifth is a "NON STANDARD" way that GNAT introduce with the
pre-release of Ada_2005 which is to use the "pragma Ada_05 ( name ) ;" 

Example:

-- For GNAT you can create a routine that is define and is usable 
-- only in Ada_2005 specs, by using the GNAT pragma Ada_05.
--
-- Gnat uses this concept in the  Ada.Text_IO package. Just 
-- search for "Ada_05" in the file "a-textio.ads". There are 
-- two Get_Line functions. If the system is compiled with 
-- "pragma Ada_83 ;" or "pragma Ada_95" the compile will not 
-- allow a call to these routines. But under Ada_05 the routine is 
-- visible.
--
-- Defined in the specification file.

   procedure Routine ;
   pragma Ada_05 ( Routine ) ;


--
-- Defined in the body file.
--
   procedure Routine is 
     begin -- Routine
        null ;
     end Routine ;



In <1190879769.361848.188220@22g2000hsm.googlegroups.com>,  Jerry <lanceboyle@qwest.net> writes:
>Is there a pragma to designate some lines of Ada for conditional
>compilation depending on if the compiler is Ada 2005 or not?
>
>I have made some bindings that use some of the declarations from Annex
>G.3 which relates to vector-matrix stuff which is new to Ada 2005. If
>the compiler provides those declarations (i.e., is 2005), I want to
>use the compiler's version because I figure that is the cleanest way
>to get things done. If the compiler is Ada 95, I instead want to
>provide the declarations myself.
>
>Currently, I handle this by commenting out the declarations of my own
>if Ada 2005 and uncomment them if Ada 95. (There are a couple of
>"with" and "use" lines that also have to be (un)commented but it is a
>similar situation.)
>
>I'm guessing this is an Ada "no-no" but would be interested to know
>for sure.
>
>Jerry
>

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Jerry]

On Sep 27, 8:26 am, a...@anon.org (anon) wrote:

Thanks, anon, for the detailed answer.

>
> The third real old way is to code in the option by a "IF-THEN-ELSE-END"
> statements and use a Global constant variable(s). Its low tech but it
> still works.

OK, but my "problem" is in declaring types which I want to be visible
in 95 but not visible in 05, as 05 provides them itself. An "IF-THEN-
ELSE-END" solution would have to be in the executable part of the
program (right?).


> The fifth is a "NON STANDARD" way that GNAT introduce with the
> pre-release of Ada_2005 which is to use the "pragma Ada_05 ( name ) ;"
>
> Example:
>
> -- For GNAT you can create a routine that is define and is usable
> -- only in Ada_2005 specs, by using the GNAT pragma Ada_05.
> --
> -- Gnat uses this concept in the  Ada.Text_IO package. Just
> -- search for "Ada_05" in the file "a-textio.ads". There are
> -- two Get_Line functions. If the system is compiled with
> -- "pragma Ada_83 ;" or "pragma Ada_95" the compile will not
> -- allow a call to these routines. But under Ada_05 the routine is
> -- visible.
> --
> -- Defined in the specification file.
>
>    procedure Routine ;
>    pragma Ada_05 ( Routine ) ;
>
> --
> -- Defined in the body file.
> --
>    procedure Routine is
>      begin -- Routine
>         null ;
>      end Routine ;
>
Same comment as above--how would this work for type declarations?
Could I follow the type declaration with the pragma? Also, I need to
conditionally have a with clause. For example, if using Ada 2005, I
need a line like this:

  with Ada.Numerics.Long_Real_Arrays;
  use  Ada.Numerics.Long_Real_Arrays;

(This is where the vector and matrix declarations are.)

Jerry

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Jeffrey R. Carter]

Jerry wrote:
> 
>> The third real old way is to code in the option by a "IF-THEN-ELSE-END"
>> statements and use a Global constant variable(s). Its low tech but it
>> still works.
> 
> OK, but my "problem" is in declaring types which I want to be visible
> in 95 but not visible in 05, as 05 provides them itself. An "IF-THEN-
> ELSE-END" solution would have to be in the executable part of the
> program (right?).

Despite the claim, this will not work. You cannot compile Ada-07 code 
with an Ada-95 compiler. Different bodies for different compilers, 
selected somehow (project files are a good way with GNAT, as has been 
suggested) is the best way to address this issue.

-- 
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers
48

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Jeffrey Creem]

Jeffrey R. Carter wrote:
> Jerry wrote:
>>
>>> The third real old way is to code in the option by a "IF-THEN-ELSE-END"
>>> statements and use a Global constant variable(s). Its low tech but it
>>> still works.
>>
>> OK, but my "problem" is in declaring types which I want to be visible
>> in 95 but not visible in 05, as 05 provides them itself. An "IF-THEN-
>> ELSE-END" solution would have to be in the executable part of the
>> program (right?).
> 
> Despite the claim, this will not work. You cannot compile Ada-07 code 
> with an Ada-95 compiler. Different bodies for different compilers, 
> selected somehow (project files are a good way with GNAT, as has been 
> suggested) is the best way to address this issue.
> 

I agree that in general, given where Ada is, the best way to solve these 
issues is the whole "you have a CM problem" thing...But it really is 
sort of just a mantra that we repeat and all hope it is true.

The problem is that in the C world, for good (sometimes) or evil 
(equally often) people can portably but painfully use the pre-processor 
to deal with compiler and platform portability issues.

We claim it is a CM problem but of course now you trade a language 
portability problem for a CM/build chain portability problem. Finding a 
build system or CM system that works portability is now just another 
problem to deal with.

I am not saying conditional compilation is the real answer, but pointing 
to something that is outside the language definition as the answer is 
somewhat of a cop out.

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Jean-Pierre Rosen]

Jeffrey Creem a �crit :
> I am not saying conditional compilation is the real answer, but pointing 
> to something that is outside the language definition as the answer is 
> somewhat of a cop out.

Library package renaming is a way to achieve the same effect without 
resorting to CM.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Ludovic Brenta]

Jean-Pierre Rosen writes:
> Library package renaming is a way to achieve the same effect without
> resorting to CM.

But what if you want to maintain two versions of the software in
parallel, like the OP does? You'll want two versions of the renaming.
I don't see how you'd do that without some sort of configuration
management system. OK, maybe I'm biased: I haven't worked without a
configuration management system since 1999 :)

--
Ludovic Brenta.

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Jean-Pierre Rosen]

Ludovic Brenta a �crit :
> Jean-Pierre Rosen writes:
>> Library package renaming is a way to achieve the same effect without
>> resorting to CM.
> 
> But what if you want to maintain two versions of the software in
> parallel, like the OP does? You'll want two versions of the renaming.
> I don't see how you'd do that without some sort of configuration
> management system. OK, maybe I'm biased: I haven't worked without a
> configuration management system since 1999 :)
> 
If you have something like:

with OS_Services_Linux;
package OS_Services renames OS_Services_Linux;

You certainly need to edit the source to move to -say- a Windows 
version, but I claim that it is not much more work than changing the 
value of a variable in a Make file....


-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Georg Bauhaus]

On Fri, 2007-09-28 at 18:08 +0200, Jean-Pierre Rosen wrote:
> Ludovic Brenta a écrit :
> > Jean-Pierre Rosen writes:
> >> Library package renaming is a way to achieve the same effect without
> >> resorting to CM.
> > 
> > But what if you want to maintain two versions of the software in
> > parallel, like the OP does? You'll want two versions of the renaming.
> > I don't see how you'd do that without some sort of configuration
> > management system. OK, maybe I'm biased: I haven't worked without a
> > configuration management system since 1999 :)
> > 
> If you have something like:
> 
> with OS_Services_Linux;
> package OS_Services renames OS_Services_Linux;
> 
> You certainly need to edit the source to move to -say- a Windows 
> version, but I claim that it is not much more work than changing the 
> value of a variable in a Make file....

This is fine as long as you have control over the build process.
But if I understand the OP correctly, he wishes to write his part
of the software in such a way that others can integrate in with
their build machinery. Then, an environment variable set by the
build process is the input in data driven translation control :-)

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Pascal Obry]

Note that some of the configuration management can be done directly with
GNAT Project File. In this case:

   type OS_Type is ("UNIX", "Windows_NT");
   OS : OS_Type := external ("OS", "UNIX");

   case OS is
      when "Windows_NT" =>
         for Implementation ("OS_Services")
              use "os_services__win32.adb";
      when "UNIX" =>
         for Implementation ("OS_Services")
              use "os_services__linux.adb";
   end case;

Note the double underscore to be sure that those files are not found
automatically by the project file when storing the OS specific units
with all the other sources.

Alternatively it is possible to do:

   case OS is
      when "Windows_NT" =>
         for Source_Dirs use Project'Source_Dirs & ("win32");
      when "UNIX" =>
         for Source_Dirs use Project'Source_Dirs & ("linux");
   end case;

And place the bodies in the proper directories.

Pascal.


-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Stefan Bellon]

On Fri, 28 Sep, Pascal Obry wrote:

>    case OS is
>       when "Windows_NT" =>
>          for Implementation ("OS_Services")
>               use "os_services__win32.adb";
>       when "UNIX" =>
>          for Implementation ("OS_Services")
>               use "os_services__linux.adb";
>    end case;

Interesting. What is the difference to the following (what we have been
using for some time)?

   package Naming is
      case OS is
         when "UNIX" =>
            for Body ("Plugins.Internal_Load")
              use "plugins-internal_load-unix.adb";
         when "Windows_NT" =>
            for Body ("Plugins.Internal_Load")
              use "plugins-internal_load-windows.adb";
      end case;
   end Naming;

The two Internal_Load being "separate" procedures for package body
Plugins.

Are the pros and cons versus the Implementation attribute above (which
I didn't know about until now)?

-- 
Stefan Bellon

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Pascal Obry]

Stefan,

> Interesting. What is the difference to the following (what we have been
> using for some time)?
> 
>    package Naming is
>       case OS is
>          when "UNIX" =>
>             for Body ("Plugins.Internal_Load")
>               use "plugins-internal_load-unix.adb";
>          when "Windows_NT" =>
>             for Body ("Plugins.Internal_Load")
>               use "plugins-internal_load-windows.adb";
>       end case;
>    end Naming;
> 
> The two Internal_Load being "separate" procedures for package body
> Plugins.
> 
> Are the pros and cons versus the Implementation attribute above (which
> I didn't know about until now)?

In your case I think that both units are visible from GPS. Right ? In my
case only one is visible, the one explicitly named. The other is not as
double underscore is not a proper default naming convention.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Stefan Bellon]

On Fri, 28 Sep, Pascal Obry wrote:

> In your case I think that both units are visible from GPS. Right ?

I have to admit that we do not use GPS that intensively (mainly for
debugging on Windows). :-/

But we use the very cool project files to replace Makefiles and to
easily do multi-language builds with Ada, C, and C++ using gprmake.
Having just loaded the project file in question into GPS, yes, both
files are visible there.

> In my case only one is visible, the one explicitly named. The other is
> not as double underscore is not a proper default naming convention.

Ah, that's a neat trick. Thanks for the hint!

-- 
Stefan Bellon

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Stephen Leake]

Stefan Bellon <sbellon@sbellon.de> writes:

> On Fri, 28 Sep, Pascal Obry wrote:
>
>>    case OS is
>>       when "Windows_NT" =>
>>          for Implementation ("OS_Services")
>>               use "os_services__win32.adb";
>>       when "UNIX" =>
>>          for Implementation ("OS_Services")
>>               use "os_services__linux.adb";
>>    end case;
>
> Interesting. What is the difference to the following (what we have been
> using for some time)?
>
>    package Naming is
>       case OS is
>          when "UNIX" =>
>             for Body ("Plugins.Internal_Load")
>               use "plugins-internal_load-unix.adb";
>          when "Windows_NT" =>
>             for Body ("Plugins.Internal_Load")
>               use "plugins-internal_load-windows.adb";
>       end case;
>    end Naming;
>
> The two Internal_Load being "separate" procedures for package body
> Plugins.
>
> Are the pros and cons versus the Implementation attribute above (which
> I didn't know about until now)?

The gnat reference manual (_not_ the gnat user guide) says, in section
13.13.1 Package Naming:

`Implementation'
     This is a synonym of `Body'.

So the real difference is in the double underscore.

-- 
-- Stephe

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> Note that some of the configuration management can be done directly with
> GNAT Project File. In this case:
>
>    type OS_Type is ("UNIX", "Windows_NT");
>    OS : OS_Type := external ("OS", "UNIX");
>
>    case OS is
>       when "Windows_NT" =>
>          for Implementation ("OS_Services")
>               use "os_services__win32.adb";
>       when "UNIX" =>
>          for Implementation ("OS_Services")
>               use "os_services__linux.adb";
>    end case;
>
> Note the double underscore to be sure that those files are not found
> automatically by the project file when storing the OS specific units
> with all the other sources.

I never realised you could do this .. and I thought I had read the
friendly manual, too. Thanks, Pascal!

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Pascal Obry]

Simon Wright a �crit :
> Pascal Obry <pascal@obry.net> writes:
> 
>> Note that some of the configuration management can be done directly with
>> GNAT Project File. In this case:
>>
>>    type OS_Type is ("UNIX", "Windows_NT");
>>    OS : OS_Type := external ("OS", "UNIX");

Just a side note. The trick here is that OS is defined on Windows and
the value is "Windows_NT". Using this fact we say that OS gets the "OS"
env variable or "UNIX" if not defined.

> I never realised you could do this .. and I thought I had read the
> friendly manual, too. Thanks, Pascal!

You're welcome!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Stephen Leake]

Simon Wright <simon.j.wright@mac.com> writes:

> Pascal Obry <pascal@obry.net> writes:
>
>> Note the double underscore to be sure that those files are not found
>> automatically by the project file when storing the OS specific units
>> with all the other sources.
>
> I never realised you could do this .. and I thought I had read the
> friendly manual, too. 

Me, too.

The GNAT user's guide says:

    By default, if neither the attribute `Source_Files' nor the
    attribute `Source_List_File' is given an explicit value, then each
    file in the source directories that conforms to the project's
    naming scheme (*note Naming Schemes::) is an immediate source of
    the project.

It just never occurred to me to use a file name for an Ada file that
did _not_ follow the naming convention!

I think I was implicitly assuming that any file with an .ads or .adb
extension would be accepted by gnatmake, and since that's also the
rule Emacs uses, I would not use a different extension for this
purpose.

But the actual gnatmake rule is stricter than that, so there are other
ways to violate it, while keeping the extension.

-- 
-- Stephe

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Stephen Leake]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Ludovic Brenta a �crit :
>> Jean-Pierre Rosen writes:
>>> Library package renaming is a way to achieve the same effect without
>>> resorting to CM.
>> But what if you want to maintain two versions of the software in
>> parallel, like the OP does? You'll want two versions of the renaming.
>> I don't see how you'd do that without some sort of configuration
>> management system. OK, maybe I'm biased: I haven't worked without a
>> configuration management system since 1999 :)
>> 
> If you have something like:
>
> with OS_Services_Linux;
> package OS_Services renames OS_Services_Linux;
>
> You certainly need to edit the source to move to -say- a Windows
> version, but I claim that it is not much more work than changing the
> value of a variable in a Make file....

You can have _two_ make files, in two build directories, and compile
both without editing anything. Each top-level make file can define the
relevant variables, then call a common makefile that does the real
work.

Or you can have two GNAT project files that declare source names for
package OS_Services, again in two build directories, and compile both
without editing.

You can't do that with your solution.

You need two build directories anyway, since all (or at least some of)
the object files will be different.

A true solution involves _zero_ manual steps.

-- 
-- Stephe

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[anon]

As for the "pragma Ada_05 ( name ) ;" It looks like it will not 
work for your "Ada_95" user defined package and "Ada_05" Ada 
defined package.
 
Now for conditional compilation, well I did forget to add the 
sixth one. Which is the laymans answer and it always works, if you 
follow the instructions. 
--
-- Uncomment one and only one of the following lines:
--
-- with Package_1 ; use Package_1 ;  -- Ada_95 version package

-- with Package_2 ; use Package_2 ;  -- Ada_2005 version package



Now to show one example of the IF-THEN-ELSE-END concept. And it 
is a lot of work if you have more than a couple of routines to 
set up. 

-- -------- --
-- TEST.ADB --
-- -------- --
--
-- There are a number of ways to use the "IF-THEN-ELSE-END" 
-- structure, this version is one. And it does generate code 
-- for the "IF-THEN-ELSE-END" statements.  
--

with Test1 ;

procedure test is

  --
  -- True:  use Alpha routines aka "user included package"
  --
  -- False: use Beta routine aka "system define package"
  --
  package IO_Package is new Test1 ( False ) ;

  use IO_Package ; -- Assign default package

  --
  -- Use User created package 
  --
  package Package_IO is new Test1 ( True ) ;


begin

  Put_Line.all ( "This is a test" ) ;

  Package_IO.Put_Line.all ( "Try this One" ) ;

end test ;


-- --------- --
-- TEST1.ADS --
-- --------- --

--
-- This Generic package defines the program global routines, the 
-- redefined Ada system routines and the user created routines.
--
with Ada.Text_IO ;

generic

  Configure : boolean ; 

package test1 is

  type Procedure_String_Type is access procedure ( item : String ) ;

  -------------------------------
  -- Define package procedures --
  -------------------------------
   Put_Line : Procedure_String_Type ; 

   --
   -- define other declared routines/variables needed
   --

private

  -------------------------------
  -- Emulate system procedures --
  -------------------------------
  procedure Alpha ( szTemp : string ) ;


  -----------------------------------------------
  -- Redefine/Rename system supplied procedure --
  -----------------------------------------------

  procedure Beta ( Item : in String ) renames Ada.Text_IO.Put_Line ;

end test1 ;


-- --------- --
-- TEST1.ADB --
-- --------- --

--
-- This Generic body package defines the user created routines and 
-- this package does contain a initialize routine that configures 
-- the package.
--

--
-- IF-THEN-ELSE-END -- Yes, the compiler does generate code for 
--                  -- this type of statament.
--                  -- Also, it is easy to insert a statement in
--                  -- the wrong place.
--
-- This works! Even though there is a person that says this will 
-- not work.
-- If this does not you better find a different language to use.
-- Because it means the Ada "IF" statement does not work?
--

with Ada.Text_IO ;

package body test1 is

  -------------------------------
  -- Emulate system procedures --
  -------------------------------
  procedure Alpha ( szTemp : string ) is
    begin
      Ada.Text_IO.Put_Line ( "Alpha: " & szTemp ) ;
    end ;

-----------------------
--  Initial package  --
-----------------------
  begin -- test1
     --
     -- Like I said, this is the old way of doing this by embedding 
     -- the configuration code in the source. But it does work. 
     -- Of course you could use a CASE statement instead, if you need 
     -- more than two options or packages set up.
     --
    if Configure then 
      Put_Line := Alpha'Access ;
    else
      Put_Line := Beta'Access ;
    end if ;

  end test1 ;




In <1190929570.915553.284000@19g2000hsx.googlegroups.com>,  Jerry <lanceboyle@qwest.net> writes:
>On Sep 27, 8:26 am, a...@anon.org (anon) wrote:
>
>Thanks, anon, for the detailed answer.
>
>>
>> The third real old way is to code in the option by a "IF-THEN-ELSE-END"
>> statements and use a Global constant variable(s). Its low tech but it
>> still works.
>
>OK, but my "problem" is in declaring types which I want to be visible
>in 95 but not visible in 05, as 05 provides them itself. An "IF-THEN-
>ELSE-END" solution would have to be in the executable part of the
>program (right?).
>
>
>> The fifth is a "NON STANDARD" way that GNAT introduce with the
>> pre-release of Ada_2005 which is to use the "pragma Ada_05 ( name ) ;"
>>
>> Example:
>>
>> -- For GNAT you can create a routine that is define and is usable
>> -- only in Ada_2005 specs, by using the GNAT pragma Ada_05.
>> --
>> -- Gnat uses this concept in the  Ada.Text_IO package. Just
>> -- search for "Ada_05" in the file "a-textio.ads". There are
>> -- two Get_Line functions. If the system is compiled with
>> -- "pragma Ada_83 ;" or "pragma Ada_95" the compile will not
>> -- allow a call to these routines. But under Ada_05 the routine is
>> -- visible.
>> --
>> -- Defined in the specification file.
>>
>>    procedure Routine ;
>>    pragma Ada_05 ( Routine ) ;
>>
>> --
>> -- Defined in the body file.
>> --
>>    procedure Routine is
>>      begin -- Routine
>>         null ;
>>      end Routine ;
>>
>Same comment as above--how would this work for type declarations?
>Could I follow the type declaration with the pragma? Also, I need to
>conditionally have a with clause. For example, if using Ada 2005, I
>need a line like this:
>
>  with Ada.Numerics.Long_Real_Arrays;
>  use  Ada.Numerics.Long_Real_Arrays;
>
>(This is where the vector and matrix declarations are.)
>
>Jerry
>
>

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Jerry]

Hi. OP here.

After the first round of responses to my post, I relayed my (your)
thoughts to the PLplot people (the project for which I made the
bindings). I stated a preference for not creating a GNAT dependency so
that other Ada compilers could be used. (I have no idea what the
relative usage among Ada compilers is. It is however a good guess that
PLplot will not be used in embedded systems.) I suggested that either
I or the project maintainers provide a little sed script to modify my
sources for either Ada 95 or Ada 05 and incorporate into their build
system which is CMake. Here is the response by one Alan Irwin. Note
that I might have mislead in my original post--I guess I do have a bit
of control, if indirect, over the build process 8^).

Following is from the PLplot list. I don't understand it yet but it
seems that I have to put some stuff into my source (presumably hidden
behind comment marks) and modify one of the build files.


>>>>>>
Here is what I believe is needed from the CMake perspective in order
to deal with versioned Ada bindings.

(1) Add an OPTION command to cmake/modules/ada.cmake which allows the
user to specify if they have an ada system that is capable of Ada
2007. See example below.

(2) It is a trivial matter for cmake to configure Ada bindings files
using the CONFIGURE_FILE command. A most extensive example of a file
to be configured is test/plplot-test.sh.cmake. The CONFIGURE_FILE
command in test/CMakeLists.txt replaces the many different place-
holders (variables surrounded by @ signs) by the value of the
corresponding CMake variable, and it would be straightforward to set
up something similar in bindings/ada/CMakeLists.txt. This placeholder
replacement functionality is similar to the sed approach you outlined
above but with the advantage that it is native to cmake.

Jerry, to get this rolling what I need from you are the configurable
Ada bindings files with @CMake_variable_name@ placeholders in them.
You should send that as a normal patch on the existing bindings files.
You should also send me a list of the placeholder CMake variable names
(please start each one of them with ADA so they don't clash with other
CMake variable names) and the strings those placeholders should be
changed to in the two cases of HAVE_ADA_2007=OFF or ON. To make life
simple for me, please put this into a patch for cmake/modules/
ada.cmake.

The changes should look like this:

option(HAVE_ADA_2007 "Ada 2007?" OFF)

if(HAVE_ADA_2007) set(ADA_whatever1 "replacement string for Ada 2007
case") ... else(HAVE_ADA_2007) set(ADA_whatever1 "replacement string
for non Ada 2007 case") ... endif(HAVE_ADA_2007)

where you should replace the ADA_whatever1 variable with a series of
the appropriate placeholder variable names that you have embedded into
the Ada bindings files.

Once you send me the requested patch there will be more for me to do
to get this all to work, but it should be straightforward.

>>>>>>

Jerry

Re: Pragma for conditional compilation? (Ada 2005 vs. 95)

[Stephen Leake]

Jerry <lanceboyle@qwest.net> writes:

> Following is from the PLplot list. I don't understand it yet but it
> seems that I have to put some stuff into my source (presumably hidden
> behind comment marks) and modify one of the build files.

This mechanism would be easiest to use with the package renaming
approach. You distribute a file that has:

package My_Package renames %real_package%;

and the CMake CONFIGURE_FILE command changes that to:

package My_Package renames My_Package_Ada_95;

or 

package My_Package renames My_Package_Ada_2007;

-- 
-- Stephe