* architecture-independent GNAT project files? @ 2009-04-27 7:32 Björn Persson 2009-04-27 8:02 ` Dmitry A. Kazakov 2009-04-27 12:06 ` anon 0 siblings, 2 replies; 11+ messages in thread From: Björn Persson @ 2009-04-27 7:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: architecture-independent GNAT project files? 2009-04-27 7:32 architecture-independent GNAT project files? Björn Persson @ 2009-04-27 8:02 ` Dmitry A. Kazakov 2009-04-27 21:16 ` Björn Persson 2009-04-27 12:06 ` anon 1 sibling, 1 reply; 11+ messages in thread From: Dmitry A. Kazakov @ 2009-04-27 8:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: architecture-independent GNAT project files? 2009-04-27 8:02 ` Dmitry A. Kazakov @ 2009-04-27 21:16 ` Björn Persson 2009-04-27 21:55 ` Ludovic Brenta 2009-04-28 7:24 ` Dmitry A. Kazakov 0 siblings, 2 replies; 11+ messages in thread From: Björn Persson @ 2009-04-27 21:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: architecture-independent GNAT project files? 2009-04-27 21:16 ` Björn Persson @ 2009-04-27 21:55 ` Ludovic Brenta 2009-04-28 21:41 ` Björn Persson 2009-04-28 7:24 ` Dmitry A. Kazakov 1 sibling, 1 reply; 11+ messages in thread From: Ludovic Brenta @ 2009-04-27 21:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: architecture-independent GNAT project files? 2009-04-27 21:55 ` Ludovic Brenta @ 2009-04-28 21:41 ` Björn Persson 0 siblings, 0 replies; 11+ messages in thread From: Björn Persson @ 2009-04-28 21:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: architecture-independent GNAT project files? 2009-04-27 21:16 ` Björn Persson 2009-04-27 21:55 ` Ludovic Brenta @ 2009-04-28 7:24 ` Dmitry A. Kazakov 2009-04-28 20:56 ` sjw 2009-04-30 12:17 ` Björn Persson 1 sibling, 2 replies; 11+ messages in thread From: Dmitry A. Kazakov @ 2009-04-28 7:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: architecture-independent GNAT project files? 2009-04-28 7:24 ` Dmitry A. Kazakov @ 2009-04-28 20:56 ` sjw 2009-04-30 12:17 ` Björn Persson 1 sibling, 0 replies; 11+ messages in thread From: sjw @ 2009-04-28 20:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: architecture-independent GNAT project files? 2009-04-28 7:24 ` Dmitry A. Kazakov 2009-04-28 20:56 ` sjw @ 2009-04-30 12:17 ` Björn Persson 2009-04-30 12:31 ` Ludovic Brenta 1 sibling, 1 reply; 11+ messages in thread From: Björn Persson @ 2009-04-30 12:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: architecture-independent GNAT project files? 2009-04-30 12:17 ` Björn Persson @ 2009-04-30 12:31 ` Ludovic Brenta 0 siblings, 0 replies; 11+ messages in thread From: Ludovic Brenta @ 2009-04-30 12:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: architecture-independent GNAT project files? 2009-04-27 7:32 architecture-independent GNAT project files? Björn Persson 2009-04-27 8:02 ` Dmitry A. Kazakov @ 2009-04-27 12:06 ` anon 2009-04-27 19:10 ` sjw 1 sibling, 1 reply; 11+ messages in thread From: anon @ 2009-04-27 12:06 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: architecture-independent GNAT project files? 2009-04-27 12:06 ` anon @ 2009-04-27 19:10 ` sjw 0 siblings, 0 replies; 11+ messages in thread From: sjw @ 2009-04-27 19:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-04-30 12:31 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-04-27 7:32 architecture-independent GNAT project files? Björn Persson 2009-04-27 8:02 ` Dmitry A. Kazakov 2009-04-27 21:16 ` Björn Persson 2009-04-27 21:55 ` Ludovic Brenta 2009-04-28 21:41 ` Björn Persson 2009-04-28 7:24 ` Dmitry A. Kazakov 2009-04-28 20:56 ` sjw 2009-04-30 12:17 ` Björn Persson 2009-04-30 12:31 ` Ludovic Brenta 2009-04-27 12:06 ` anon 2009-04-27 19:10 ` sjw
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox