architecture-independent GNAT project files?

architecture-independent GNAT project files?

[Björn Persson]

When I write GNAT project files for shared libraries I find that I have to
hardcode the paths to some architecture-specific directories. 32-bit
libraries are in /usr/lib/ while 64-bit libraries are in /usr/lib64/, and I
would like to have a single project file that works for both cases.

The way to find out the architecture of a Unix-like system appears to be to
invoke uname, but GNAT project files don't seem to have a shell-out
feature. As far as I can see in the manual the only ways they can get input
is by environment variables and command line parameters. I don't suppose
Gnatmake provides some variable to project files that shows what the
architecture is?

I could define an environment variable in the systemwide profile, but that's
not really a good solution. That variable would contain the host
architecture but it's the target architecture I really need to test for. I
also don't like polluting the environment.

Does anyone have a better idea?

-- 
Bj�rn Persson
PGP key A88682FD

Re: architecture-independent GNAT project files?

[Dmitry A. Kazakov]

On Mon, 27 Apr 2009 09:32:29 +0200, Bj�rn Persson wrote:

> When I write GNAT project files for shared libraries I find that I have to
> hardcode the paths to some architecture-specific directories. 32-bit
> libraries are in /usr/lib/ while 64-bit libraries are in /usr/lib64/, and I
> would like to have a single project file that works for both cases.

The way I am using is to have a platform variable in the project file:

   type Platform_Type is ("x86_Windows", "x86_VxWorks");
   Platform : Platform_Type := external ("Platform", "x86_Windows");

and then somewhere later

   case Platform is
      when "x86_Windows" =>
         for Source_Dirs use "os/Windows/i586" & ...;
      when "x86_VxWorks" =>
         for Source_Dirs use "os/vxworks/i586" & ...;
   end case;

then same for library things etc.

> The way to find out the architecture of a Unix-like system appears to be to
> invoke uname, but GNAT project files don't seem to have a shell-out
> feature. As far as I can see in the manual the only ways they can get input
> is by environment variables and command line parameters. I don't suppose
> Gnatmake provides some variable to project files that shows what the
> architecture is?

I don't know if it has, but if any, how that is supposed to work for cross
platform developing?

> Does anyone have a better idea?

I would like to hear it too, because the solution I am using is a bit
obtrusive.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: architecture-independent GNAT project files?

[Björn Persson]

Dmitry A. Kazakov wrote:

> On Mon, 27 Apr 2009 09:32:29 +0200, Bj�rn Persson wrote:
> 
>> When I write GNAT project files for shared libraries I find that I have
>> to hardcode the paths to some architecture-specific directories. 32-bit
>> libraries are in /usr/lib/ while 64-bit libraries are in /usr/lib64/, and
>> I would like to have a single project file that works for both cases.
> 
> The way I am using is to have a platform variable in the project file:
> 
>    type Platform_Type is ("x86_Windows", "x86_VxWorks");
>    Platform : Platform_Type := external ("Platform", "x86_Windows");
> 
> and then somewhere later
> 
>    case Platform is
>       when "x86_Windows" =>
>          for Source_Dirs use "os/Windows/i586" & ...;
>       when "x86_VxWorks" =>
>          for Source_Dirs use "os/vxworks/i586" & ...;
>    end case;
> 
> then same for library things etc.

The analog for my case would be:

   type Architecture is ("i386", "x86_64");
   Target : Architecture := external ("Target", "i386");

The problem with that is of course that on x86_64 systems the default will
almost always be wrong, and if I set the default to x86_64 it will be wrong
on i386 systems.

>> The way to find out the architecture of a Unix-like system appears to be
>> to invoke uname, but GNAT project files don't seem to have a shell-out
>> feature. As far as I can see in the manual the only ways they can get
>> input is by environment variables and command line parameters. I don't
>> suppose Gnatmake provides some variable to project files that shows what
>> the architecture is?
> 
> I don't know if it has, but if any, how that is supposed to work for cross
> platform developing?

The cross-compiler would know its target platform and would assign that
value to the hypothetical variable. The project file would then select the
right library directories for that platform.

Such a feature, if done right, could make it possible to write project files
that would work for anything from ARM to Itanium, but I wasn't planning to
do that. I'm satisfied if I can support a multilib environment so that i386
libraries will be selected if someone uses the -m32 parameter on an x86_64
platform. For true cross-compilation I guess the cross-compiler will
normally have a completely separate set of libraries, including a separate
project file directory.

-- 
Bj�rn Persson
PGP key A88682FD

Re: architecture-independent GNAT project files?

[Ludovic Brenta]

Björn Persson wrote on comp.lang.ada:
> >> The way to find out the architecture of a Unix-like system appears to be
> >> to invoke uname, but GNAT project files don't seem to have a shell-out
> >> feature. As far as I can see in the manual the only ways they can get
> >> input is by environment variables and command line parameters. I don't
> >> suppose Gnatmake provides some variable to project files that shows what
> >> the architecture is?
>
> > I don't know if it has, but if any, how that is supposed to work for cross
> > platform developing?
>
> The cross-compiler would know its target platform and would assign that
> value to the hypothetical variable. The project file would then select the
> right library directories for that platform.

Yes. "gcc -v | grep ^Target:" yields the correct information.  I
normally use a minimal Makefile to set up such variables from the
environment and then invoke gnatmake, passing it the variables.

> Such a feature, if done right, could make it possible to write project files
> that would work for anything from ARM to Itanium, but I wasn't planning to
> do that. I'm satisfied if I can support a multilib environment so that i386
> libraries will be selected if someone uses the -m32 parameter on an x86_64
> platform. For true cross-compilation I guess the cross-compiler will
> normally have a completely separate set of libraries, including a separate
> project file directory.

It is my understanding that "gcc -m32" invokes the linker in such a
way (i.e. "ld -melf_i386", "ld -mi386linux" or some such) that it
automatically selects /usr/lib64 instead of /usr/lib.  Is that not the
case?

If I'm right, your problem disappars as far as binary libraries go but
still exists for target-dependent source files.

--
Ludovic Brenta.

Re: architecture-independent GNAT project files?

[Björn Persson]

Ludovic Brenta wrote:

> Yes. "gcc -v | grep ^Target:" yields the correct information.  I
> normally use a minimal Makefile to set up such variables from the
> environment and then invoke gnatmake, passing it the variables.

Neither -m32 nor the setarch command seem to affect the output of "gcc -v".
Anyway, I was hoping to avoid putting a wrapper around gnatmake.
 
> It is my understanding that "gcc -m32" invokes the linker in such a
> way (i.e. "ld -melf_i386", "ld -mi386linux" or some such) that it
> automatically selects /usr/lib64 instead of /usr/lib.  Is that not the
> case?
> 
> If I'm right, your problem disappars as far as binary libraries go but
> still exists for target-dependent source files.

I don't know how ld is invoked, but it's not only a matter of finding the
right .so file. The ALI files appear to be architecture-specific, and their
location is specified in the project file with the Library_ALI_Dir
attribute.

-- 
Bj�rn Persson
PGP key A88682FD

Re: architecture-independent GNAT project files?

[Dmitry A. Kazakov]

On Mon, 27 Apr 2009 23:16:13 +0200, Bj�rn Persson wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Mon, 27 Apr 2009 09:32:29 +0200, Bj�rn Persson wrote:
>> 
>>> When I write GNAT project files for shared libraries I find that I have
>>> to hardcode the paths to some architecture-specific directories. 32-bit
>>> libraries are in /usr/lib/ while 64-bit libraries are in /usr/lib64/, and
>>> I would like to have a single project file that works for both cases.
>> 
>> The way I am using is to have a platform variable in the project file:
>> 
>>    type Platform_Type is ("x86_Windows", "x86_VxWorks");
>>    Platform : Platform_Type := external ("Platform", "x86_Windows");
>> 
>> and then somewhere later
>> 
>>    case Platform is
>>       when "x86_Windows" =>
>>          for Source_Dirs use "os/Windows/i586" & ...;
>>       when "x86_VxWorks" =>
>>          for Source_Dirs use "os/vxworks/i586" & ...;
>>    end case;
>> 
>> then same for library things etc.
> 
> The analog for my case would be:
> 
>    type Architecture is ("i386", "x86_64");
>    Target : Architecture := external ("Target", "i386");
> 
> The problem with that is of course that on x86_64 systems the default will
> almost always be wrong, and if I set the default to x86_64 it will be wrong
> on i386 systems.

New GPS remembers the last choices of the project variables (well almost
always (:-)). So it should not be a great problem. Of course object and
executable files have to land into disparate directories (switched by the
same variable).

>>> The way to find out the architecture of a Unix-like system appears to be
>>> to invoke uname, but GNAT project files don't seem to have a shell-out
>>> feature. As far as I can see in the manual the only ways they can get
>>> input is by environment variables and command line parameters. I don't
>>> suppose Gnatmake provides some variable to project files that shows what
>>> the architecture is?
>> 
>> I don't know if it has, but if any, how that is supposed to work for cross
>> platform developing?
> 
> The cross-compiler would know its target platform and would assign that
> value to the hypothetical variable. The project file would then select the
> right library directories for that platform.

Hmm, I see no obvious way to do it. In my case there are several GNAT
compilers installed. The project variable Platform chooses the compiler as
well. For example, I have:

   package Ide is
      case Platform is
         when "x86_Windows" =>
            for Gnatlist use "gnatls";
            for Gnat use "gnat";
            for Compiler_Command ("ada") use "gnatmake";
            for Debugger_Command use "gdb";
         when "x86_VxWorks" =>
            for Gnatlist use "i586-wrs-vxworks-gnatls";
            for Gnat use "i586-wrs-vxworks-gnat";
            for Compiler_Command ("ada") use "i586-wrs-vxworks-gnatmake";
            for Debugger_Command use "i586-wrs-vxworks6-gdb";
      end case;
   end Ide;

This changes gnatlist, gnat, gnatmake, everything...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: architecture-independent GNAT project files?

[sjw]

On Apr 28, 8:24 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> Hmm, I see no obvious way to do it. In my case there are several GNAT
> compilers installed. The project variable Platform chooses the compiler as
> well. For example, I have:
>
>    package Ide is
>       case Platform is
>          when "x86_Windows" =>
>             for Gnatlist use "gnatls";
>             for Gnat use "gnat";
>             for Compiler_Command ("ada") use "gnatmake";
>             for Debugger_Command use "gdb";
>          when "x86_VxWorks" =>
>             for Gnatlist use "i586-wrs-vxworks-gnatls";
>             for Gnat use "i586-wrs-vxworks-gnat";
>             for Compiler_Command ("ada") use "i586-wrs-vxworks-gnatmake";
>             for Debugger_Command use "i586-wrs-vxworks6-gdb";
>       end case;
>    end Ide;
>
> This changes gnatlist, gnat, gnatmake, everything...

If you say

  $ gnatmake -Pdmitry.gpr -XPlatform=x86_VxWorks

does it swap then? When we wrote our Project files we weren't aware of
Compiler_Command, in fact it may not even have been available, so we
have to name the compiler as well as setting the variables:

  $ i586-wrs-vxworks6-gnatmake -Pdmitry.gpr -XPlatform=x86_VxWorks

Of course, once the makefiles are set up it doesn't make a heap of
difference.

Re: architecture-independent GNAT project files?

[Björn Persson]

Dmitry A. Kazakov wrote:

> On Mon, 27 Apr 2009 23:16:13 +0200, Bj�rn Persson wrote:
> 
>> The analog for my case would be:
>> 
>>    type Architecture is ("i386", "x86_64");
>>    Target : Architecture := external ("Target", "i386");
>> 
>> The problem with that is of course that on x86_64 systems the default
>> will almost always be wrong, and if I set the default to x86_64 it will
>> be wrong on i386 systems.
> 
> New GPS remembers the last choices of the project variables (well almost
> always (:-)). So it should not be a great problem. Of course object and
> executable files have to land into disparate directories (switched by the
> same variable).

I'm not writing for GPS only. I want commands like "gnatmake -P project" to
do the right thing without additional parameters.

If I use a global environment variable I will at least be right for the
common case of compiling for the native platform.

>> The cross-compiler would know its target platform and would assign that
>> value to the hypothetical variable. The project file would then select
>> the right library directories for that platform.
> 
> Hmm, I see no obvious way to do it. In my case there are several GNAT
> compilers installed. The project variable Platform chooses the compiler as
> well. For example, I have:
> 
>    package Ide is
>       case Platform is
>          when "x86_Windows" =>
>             for Gnatlist use "gnatls";
>             for Gnat use "gnat";
>             for Compiler_Command ("ada") use "gnatmake";
>             for Debugger_Command use "gdb";
>          when "x86_VxWorks" =>
>             for Gnatlist use "i586-wrs-vxworks-gnatls";
>             for Gnat use "i586-wrs-vxworks-gnat";
>             for Compiler_Command ("ada") use "i586-wrs-vxworks-gnatmake";
>             for Debugger_Command use "i586-wrs-vxworks6-gdb";
>       end case;
>    end Ide;
> 
> This changes gnatlist, gnat, gnatmake, everything...

Is that a new feature that hasn't been merged into GCC yet? I don't see
those attributes in the GNAT User's Guide of GCC 4.4.0.

Are those attributes only for GPS or does the "gnat" driver actually invoke
the VxWorks version of itself if you run
"gnat -P project -XPlatform=x86_VxWorks"?

I was thinking you'd run "i586-wrs-vxworks-gnatmake -P project" from a
command prompt, and i586-wrs-vxworks-gnatmake would set Platform
to "x86_VxWorks" (or more likely "i586-wrs-vxworks").

-- 
Bj�rn Persson
PGP key A88682FD

Re: architecture-independent GNAT project files?

[Ludovic Brenta]

On Apr 30, 2:17 pm, Björn Persson <bj...@xn--rombobjrn-67a.se> wrote:
> Dmitry A. Kazakov wrote:
[...]
> >    package Ide is
> >       case Platform is
> >          when "x86_Windows" =>
> >             for Gnatlist use "gnatls";
> >             for Gnat use "gnat";
> >             for Compiler_Command ("ada") use "gnatmake";
> >             for Debugger_Command use "gdb";
> >          when "x86_VxWorks" =>
> >             for Gnatlist use "i586-wrs-vxworks-gnatls";
> >             for Gnat use "i586-wrs-vxworks-gnat";
> >             for Compiler_Command ("ada") use "i586-wrs-vxworks-gnatmake";
> >             for Debugger_Command use "i586-wrs-vxworks6-gdb";
> >       end case;
> >    end Ide;
>
> > This changes gnatlist, gnat, gnatmake, everything...
>
> Is that a new feature that hasn't been merged into GCC yet? I don't see
> those attributes in the GNAT User's Guide of GCC 4.4.0.
>
> Are those attributes only for GPS or does the "gnat" driver actually invoke
> the VxWorks version of itself if you run
> "gnat -P project -XPlatform=x86_VxWorks"?
>
> I was thinking you'd run "i586-wrs-vxworks-gnatmake -P project" from a
> command prompt, and i586-wrs-vxworks-gnatmake would set Platform
> to "x86_VxWorks" (or more likely "i586-wrs-vxworks").

The package IDE in project files is for use by GPS; GPS parses it and
uses the supplied command names when invoking the compiler, binder,
linker etc. Gnatmake ignores this package, so your example wouldn't
work.

--
Ludovic Brenta.

Re: architecture-independent GNAT project files?

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

You could use: -gnateD on your command line or GPS options list

  -gnateD?  Define or redefine preprocessing symbol, e.g. -gnateDsym=val

Where use could set a variable to the architecture path you wish to use 
such as for a 32-bit arch

gnat make  -gnateDArchLib="/usr/lib/'  <filename>

     then for the 64 bit arch use

gnat make   -gnateDArchLib="/usr/lib64/'   <filename>


--
--  ArchLib is define in commnd line options. if not present an error 
--  will be generated.
--
   Libs_Path : String := ArchLib ;

   ...

   open ( File => LibFlile, 
          Name => Libs_Path & FileName, 
          Mode => In_File ) ;



In <75l5ceF18samiU1@mid.individual.net>, =?ISO-8859-1?Q?Bj=F6rn?= Persson <bjorn@xn--rombobjrn-67a.se> writes:
>When I write GNAT project files for shared libraries I find that I have to
>hardcode the paths to some architecture-specific directories. 32-bit
>libraries are in /usr/lib/ while 64-bit libraries are in /usr/lib64/, and I
>would like to have a single project file that works for both cases.
>
>The way to find out the architecture of a Unix-like system appears to be to
>invoke uname, but GNAT project files don't seem to have a shell-out
>feature. As far as I can see in the manual the only ways they can get input
>is by environment variables and command line parameters. I don't suppose
>Gnatmake provides some variable to project files that shows what the
>architecture is?
>
>I could define an environment variable in the systemwide profile, but that's
>not really a good solution. That variable would contain the host
>architecture but it's the target architecture I really need to test for. I
>also don't like polluting the environment.
>
>Does anyone have a better idea?
>
>-- 
>Bj�rn Persson
>PGP key A88682FD

Re: architecture-independent GNAT project files?

[sjw]

On Apr 27, 1:06 pm, a...@anon.org (anon) wrote:
> You could use: -gnateD on your command line or GPS options list
>
>   -gnateD?  Define or redefine preprocessing symbol, e.g. -gnateDsym=val
>
> Where use could set a variable to the architecture path you wish to use
> such as for a 32-bit arch
>
> gnat make  -gnateDArchLib="/usr/lib/'  <filename>
>
>      then for the 64 bit arch use
>
> gnat make   -gnateDArchLib="/usr/lib64/'   <filename>
>
> --
> --  ArchLib is define in commnd line options. if not present an error
> --  will be generated.
> --
>    Libs_Path : String := ArchLib ;
>
>    ...
>
>    open ( File => LibFlile,
>           Name => Libs_Path & FileName,
>           Mode => In_File ) ;

This sounds very like the -X flag. I wonder why there are 2 ways of
doing the same thing?

Oh, -gnatD is a preprocessor flag, sounds like it's for a different
purpose? (gnatprep).

Personally I use -Xsym=val in Makefiles.