* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 15:51 How to supply O/S linker arguments with gprbuild? Warren
@ 2020-06-22 16:14 ` Mark Lorenzen
2020-06-22 16:30 ` Dennis Lee Bieber
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Mark Lorenzen @ 2020-06-22 16:14 UTC (permalink / raw)
On Monday, June 22, 2020 at 5:51:50 PM UTC+2, Warren wrote:
> I have a GNAT project that has these pragma statements embedded to get the sucker to link. However, the directory is only valid for an instance on my Mac, so I need a better solution to replace:
>
> pragma Linker_Options("-L/usr/local/Cellar/readline/8.0.4/lib");
> pragma Linker_Options("-lreadline");
>
> I've tried to find the solution in the gnat documents but they seem to fall short of what I need to do (could not find an example nor direction in this -- perhaps I missed it).
>
> My project file looks something like this:
>
> project MyProject is
> for Languages use ("ada", "c");
> for Source_Dirs use ("src");
> for Object_Dir use "obj";
> for Main use ("main.adb");
> end MyProject;
>
> I've tried a variety of gpr things, but unsuccessfully.
>
> Warren
Take a look at this tiny example project file: http://docs.adacore.com/live/wave/gprbuild/html/gprbuild_ug/gprbuild_ug/gnat_project_manager.html#tools-options-in-project-files
You want to configure the linker options in package Linker. You can select between Mac, Linux, Windows, whatever using scenario variables: http://docs.adacore.com/live/wave/gprbuild/html/gprbuild_ug/gprbuild_ug/gnat_project_manager.html#scenarios-in-projects
Regards,
Mark L
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 15:51 How to supply O/S linker arguments with gprbuild? Warren
2020-06-22 16:14 ` Mark Lorenzen
@ 2020-06-22 16:30 ` Dennis Lee Bieber
2020-06-22 16:39 ` Dmitry A. Kazakov
2020-06-23 9:23 ` Björn Lundin
3 siblings, 0 replies; 14+ messages in thread
From: Dennis Lee Bieber @ 2020-06-22 16:30 UTC (permalink / raw)
On Mon, 22 Jun 2020 08:51:48 -0700 (PDT), Warren <ve3wwg@gmail.com>
declaimed the following:
>
>I've tried a variety of gpr things, but unsuccessfully.
>
I've not used gprbuild (my personal experiments work with gnatmake, and
my pre-retirement life either didn't use GNAT or wrapped some department
specific build system around it)
Based upon
https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/building_with_gprbuild.html
you should have the option of putting them on the command line invoking
gprbuild
"""
-largs
The arguments that follow up to the next command line separator are options
for the linker, when linking an executable.
"""
Suspect it still requires something on the command line (to define
environment) but...
https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager.html#package-linker-attributes
in conjunction with
https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager.html#case-constructions
may be applicable -- and, at least, reduces the amount of command line
entry needed.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 15:51 How to supply O/S linker arguments with gprbuild? Warren
2020-06-22 16:14 ` Mark Lorenzen
2020-06-22 16:30 ` Dennis Lee Bieber
@ 2020-06-22 16:39 ` Dmitry A. Kazakov
2020-06-22 17:52 ` Warren
2020-06-23 9:23 ` Björn Lundin
3 siblings, 1 reply; 14+ messages in thread
From: Dmitry A. Kazakov @ 2020-06-22 16:39 UTC (permalink / raw)
On 22/06/2020 17:51, Warren wrote:
> I have a GNAT project that has these pragma statements embedded to get the sucker to link. However, the directory is only valid for an instance on my Mac, so I need a better solution to replace:
>
> pragma Linker_Options("-L/usr/local/Cellar/readline/8.0.4/lib");
> pragma Linker_Options("-lreadline");
>
> I've tried to find the solution in the gnat documents but they seem to fall short of what I need to do (could not find an example nor direction in this -- perhaps I missed it).
>
> My project file looks something like this:
>
> project MyProject is
> for Languages use ("ada", "c");
> for Source_Dirs use ("src");
> for Object_Dir use "obj";
> for Main use ("main.adb");
> end MyProject;
>
> I've tried a variety of gpr things, but unsuccessfully.
There are many ways to do this.
Here I give one rarely used but most flexible and consistent with the
idea of projects.
If you have an alien library like readline, you can pack it in a
separate library project like this:
project Readline is
for Externally_Built use "true"; -- Do not build it
for Source_Files use (); -- No sources
for Library_Dir use "/usr/local/Cellar/readline/8.0.4/lib";
for Library_Name use "readline"; -- OS naming conventions applied
for Library_Kind use "dynamic"; -- Or static,
end Readline; -- depending on what you have
In your project or projects you would simply do
with "readline.gpr";
and that is all.
Adjust the above using a scenario variable to select the target OS, e.g.
type OS_Type is
( "Windows", "Windows_NT",
"Linux",
"UNIX",
"OSX",
"FreeBSD",
...
);
Target_OS : OS_Type := external ("Target_OS", "MS-DOS");
case Target_OS is
when "ms-dos" =>
for Library_Dir use "...";
when "osx" =>
for Library_Dir use "...";
...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 16:39 ` Dmitry A. Kazakov
@ 2020-06-22 17:52 ` Warren
2020-06-22 20:07 ` Dmitry A. Kazakov
0 siblings, 1 reply; 14+ messages in thread
From: Warren @ 2020-06-22 17:52 UTC (permalink / raw)
On Monday, 22 June 2020 12:39:05 UTC-4, Dmitry A. Kazakov wrote:
> On 22/06/2020 17:51, Warren wrote:
> > I have a GNAT project that has these pragma statements embedded to get the sucker to link. However, the directory is only valid for an instance on my Mac, so I need a better solution to replace:
> >
> > pragma Linker_Options("-L/usr/local/Cellar/readline/8.0.4/lib");
> > pragma Linker_Options("-lreadline");
> >
> > I've tried to find the solution in the gnat documents but they seem to fall short of what I need to do (could not find an example nor direction in this -- perhaps I missed it).
> >
> > My project file looks something like this:
> >
> > project MyProject is
> > for Languages use ("ada", "c");
> > for Source_Dirs use ("src");
> > for Object_Dir use "obj";
> > for Main use ("main.adb");
> > end MyProject;
> >
> > I've tried a variety of gpr things, but unsuccessfully.
>
> There are many ways to do this.
>
> Here I give one rarely used but most flexible and consistent with the
> idea of projects.
>
> If you have an alien library like readline, you can pack it in a
> separate library project like this:
>
> project Readline is
> for Externally_Built use "true"; -- Do not build it
> for Source_Files use (); -- No sources
> for Library_Dir use "/usr/local/Cellar/readline/8.0.4/lib";
> for Library_Name use "readline"; -- OS naming conventions applied
> for Library_Kind use "dynamic"; -- Or static,
> end Readline; -- depending on what you have
>
> In your project or projects you would simply do
>
> with "readline.gpr";
>
> and that is all.
>
> Adjust the above using a scenario variable to select the target OS, e.g.
>
> type OS_Type is
> ( "Windows", "Windows_NT",
> "Linux",
> "UNIX",
> "OSX",
> "FreeBSD",
> ...
> );
> Target_OS : OS_Type := external ("Target_OS", "MS-DOS");
>
> case Target_OS is
> when "ms-dos" =>
> for Library_Dir use "...";
> when "osx" =>
> for Library_Dir use "...";
> ...
The above might be useful for some projects, but I didn't want to define a package for each and every library I link with. I have a simple Makefile that drives this project, and I simply wanted a central place to configure the pathnames.
So I managed to get this to work:
project MyProject is
for Languages use ("ada", "c");
for Source_Dirs use ("src");
for Object_Dir use "obj";
for Main use ("main.adb");
package Linker is
for Required_Switches use ( "-L/usr/local/Cellar/readline/8.0.4/lib", "-lreadline" );
end Linker;
end MyProject;
In the final version of the .gpr file, I'll put some sentinel text like <readline_dir> and substitute it as required using sed from the Makefile. Currently there is only one path I have to deal with but it might grow to several. I didn't want to define a package for each and every library referenced.
I find it amazing that there isn't a single instance of an example like this that I could goggle. The gprbuild doc seems to expend a great deal explaining every other use case, including building of library packages. All I wanted to do was to link an executable. That said, it is possible that my failing eyesight may have overlooked it.
Thanks everyone,
Warren
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 17:52 ` Warren
@ 2020-06-22 20:07 ` Dmitry A. Kazakov
2020-06-22 20:43 ` Simon Wright
0 siblings, 1 reply; 14+ messages in thread
From: Dmitry A. Kazakov @ 2020-06-22 20:07 UTC (permalink / raw)
On 22/06/2020 19:52, Warren wrote:
> The above might be useful for some projects, but I didn't want to define a package for each and every library I link with.
Actually this is the way. I have 20+ alien libraries from GTK: atk,
glib, gobject etc, all of them have a separate project file.
The linker switches you use are the end-of-the-chain parameters. They
are ignored everywhere else, but when you build an executable. E.g. if
you build a library and specify some linker switches for it, you will be
warned that they are ignored.
Thus you have to copy-paste the package linker from one project to
another once you have more than one. It is not scalable and barely
maintainable.
For this case people usually define empty parent projects with switches
or strings set there and pull them into the executable projects
combining the linker switches from various sources. It is not nice.
The library parameters for the linker that are indeed transferred from
the library project to the executable project are specified rather using:
Library_Options (and similar attributes)
not per switches. See
https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager.html#building-libraries
The solution based on Library_Options is almost as good as separate
third-party library projects if all your third-party dependencies are
always come through your libraries. Yet there is still a chance to have
conflicting definitions along different paths from different libraries.
E.g. if you have dependencies like (tree)
A C
\ /
B
|
D
You are OK with Library_Options.
But if you have this (ADG)
A
/ \
B C
\ /
D
there is a chance that B and C could have conflicting definitions
regarding A.
If each library has a project you will never have conflicts and there
always be only one place to change library options, the library project.
> I have a simple Makefile that drives this project, and I simply wanted a central place to configure the pathnames.
Another idea to consider would be to ditch makefiles. gprbuild does
everything makefiles do and better and more.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 20:07 ` Dmitry A. Kazakov
@ 2020-06-22 20:43 ` Simon Wright
2020-06-22 20:59 ` Warren
2020-06-22 21:16 ` Dmitry A. Kazakov
0 siblings, 2 replies; 14+ messages in thread
From: Simon Wright @ 2020-06-22 20:43 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Another idea to consider would be to ditch makefiles. gprbuild does
> everything makefiles do and better and more.
Almost everything! except determining which OS you're running under, or
building project documentation, or ...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 20:43 ` Simon Wright
@ 2020-06-22 20:59 ` Warren
2020-06-22 21:52 ` Simon Wright
2020-06-22 21:16 ` Dmitry A. Kazakov
1 sibling, 1 reply; 14+ messages in thread
From: Warren @ 2020-06-22 20:59 UTC (permalink / raw)
On Monday, 22 June 2020 16:43:32 UTC-4, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
> > Another idea to consider would be to ditch makefiles. gprbuild does
> > everything makefiles do and better and more.
>
> Almost everything! except determining which OS you're running under, or
> building project documentation, or ...
That may be true, but I have a lifetime of experience in make. I only have a newb's level of experience with gprbuild and I find the documentation for gprbuild frightful. It talks a lot about syntax, but find it lacking in examples that would apply to the Unix build experience.
What's important for now is just getting this project off the ground in a reasonably portable way. It's just a pet project to give me an excuse to do Ada again. The Ada experience has been good. I'll wade more into gprbuild at a later time.
Warren
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 20:59 ` Warren
@ 2020-06-22 21:52 ` Simon Wright
0 siblings, 0 replies; 14+ messages in thread
From: Simon Wright @ 2020-06-22 21:52 UTC (permalink / raw)
Warren <ve3wwg@gmail.com> writes:
> I find the documentation for gprbuild frightful. It talks a lot about
> syntax, but find it lacking in examples that would apply to the Unix
> build experience.
Yes. It always takes me a while to find out what attributes are allowed
in a particular package. And the interaction between Switches,
Default_Switches, Global_Compilation_Switches, ...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 20:43 ` Simon Wright
2020-06-22 20:59 ` Warren
@ 2020-06-22 21:16 ` Dmitry A. Kazakov
2020-06-22 21:27 ` Warren
2020-06-22 21:47 ` Simon Wright
1 sibling, 2 replies; 14+ messages in thread
From: Dmitry A. Kazakov @ 2020-06-22 21:16 UTC (permalink / raw)
On 22/06/2020 22:43, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> Another idea to consider would be to ditch makefiles. gprbuild does
>> everything makefiles do and better and more.
>
> Almost everything! except determining which OS you're running under, or
> building project documentation, or ...
Are you sure that make has OS macro defined? [It would be great to have
host OS/architecture + target OS/architecture attributes in gpr. I do
not understand why gpruild still does not have them.]
Isn't there the package Documentation in grpbuild? [I must admit I never
used it because I believe documentation must be written, not built.]
If you rather mean project cross reference GPS does the job to me.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 21:16 ` Dmitry A. Kazakov
@ 2020-06-22 21:27 ` Warren
2020-06-22 21:47 ` Simon Wright
1 sibling, 0 replies; 14+ messages in thread
From: Warren @ 2020-06-22 21:27 UTC (permalink / raw)
On Monday, 22 June 2020 17:16:50 UTC-4, Dmitry A. Kazakov wrote:
> On 22/06/2020 22:43, Simon Wright wrote:
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> >
> >> Another idea to consider would be to ditch makefiles. gprbuild does
> >> everything makefiles do and better and more.
> >
> > Almost everything! except determining which OS you're running under, or
> > building project documentation, or ...
>
> Are you sure that make has OS macro defined? [It would be great to have
> host OS/architecture + target OS/architecture attributes in gpr. I do
> not understand why gpruild still does not have them.]
>
> Isn't there the package Documentation in grpbuild? [I must admit I never
> used it because I believe documentation must be written, not built.]
>
> If you rather mean project cross reference GPS does the job to me.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
I don't need the OS defined in make. All I need is agree on a few conventions such as PREFIX and define some easily customized macros at the top of the Make file.
Even knowing that your OS is Linux, doesn't really help. While there are the usual standard places for libraries, there is no guarantee that you'll be linking with those directories. On an older CentOS for example, the newer updates are often installed in custom places like /opt because the older libraries must be maintained for the rest of the system. Shared libraries can be quite the nightmare with the inter-dependencies and versions (same deal as the Windows DLL hell).
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 21:16 ` Dmitry A. Kazakov
2020-06-22 21:27 ` Warren
@ 2020-06-22 21:47 ` Simon Wright
2020-06-22 22:08 ` Jeffrey R. Carter
1 sibling, 1 reply; 14+ messages in thread
From: Simon Wright @ 2020-06-22 21:47 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On 22/06/2020 22:43, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> Another idea to consider would be to ditch makefiles. gprbuild does
>>> everything makefiles do and better and more.
>>
>> Almost everything! except determining which OS you're running under, or
>> building project documentation, or ...
>
> Are you sure that make has OS macro defined? [It would be great to
> have host OS/architecture + target OS/architecture attributes in
> gpr. I do not understand why gpruild still does not have them.]
The first page of Gnoga's Makefile has
ifeq ($(strip $(findstring darwin, $(TARGET))),darwin)
PRJ_TARGET=OSX
else
ifeq ($(strip $(findstring mingw32, $(TARGET))),mingw32)
PRJ_TARGET=Windows
else
etc etc etc
but I agree it'd be much better to have something built-in. The internal
mechanisms of gprconfig would support this kind of thing, in fact they
already do because of knowing hw to build .so/.dll/.dylib depending in
OS, I wonder whether we could surface that?
> Isn't there the package Documentation in grpbuild? [I must admit I
> never used it because I believe documentation must be written, not
> built.]
I just had a look at this, it works on @param-style comments (and, in
the CE 2019 version anyway, goes away and builds "documentation" for all
the withed units from eg GNATCOLL unless you tell it
--no-subprojects. I'd have expected that to be the default.)
> If you rather mean project cross reference GPS does the job to me.
I use Emacs ada-mode, but yes.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 21:47 ` Simon Wright
@ 2020-06-22 22:08 ` Jeffrey R. Carter
0 siblings, 0 replies; 14+ messages in thread
From: Jeffrey R. Carter @ 2020-06-22 22:08 UTC (permalink / raw)
On 6/22/20 11:47 PM, Simon Wright wrote:
>
> The first page of Gnoga's Makefile has
>
> ifeq ($(strip $(findstring darwin, $(TARGET))),darwin)
> PRJ_TARGET=OSX
> else
> ifeq ($(strip $(findstring mingw32, $(TARGET))),mingw32)
> PRJ_TARGET=Windows
> else
> etc etc etc
Where TARGET is defined as
TARGET=$(shell gcc -dumpmachine)
--
Jeff Carter
"Death awaits you all, with nasty, big, pointy teeth!"
Monty Python & the Holy Grail
20
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to supply O/S linker arguments with gprbuild?
2020-06-22 15:51 How to supply O/S linker arguments with gprbuild? Warren
` (2 preceding siblings ...)
2020-06-22 16:39 ` Dmitry A. Kazakov
@ 2020-06-23 9:23 ` Björn Lundin
3 siblings, 0 replies; 14+ messages in thread
From: Björn Lundin @ 2020-06-23 9:23 UTC (permalink / raw)
Den 2020-06-22 kl. 17:51, skrev Warren:
> I have a GNAT project that has these pragma statements embedded to get the sucker to link. However, the directory is only valid for an instance on my Mac, so I need a better solution to replace:
>
> pragma Linker_Options("-L/usr/local/Cellar/readline/8.0.4/lib");
> pragma Linker_Options("-lreadline");
>
> I've tried to find the solution in the gnat documents but they seem to fall short of what I need to do (could not find an example nor direction in this -- perhaps I missed it).
>
> My project file looks something like this:
>
> project MyProject is
> for Languages use ("ada", "c");
> for Source_Dirs use ("src");
> for Object_Dir use "obj";
> for Main use ("main.adb");
> end MyProject;
>
> I've tried a variety of gpr things, but unsuccessfully.
>
> Warren
>
This was just (basically) discussed recently in thread
'Checking for OS in gnatstudio project file(.gpr)'
I replied with scnenario/environment variables does the trick
db_libs := ();
case db is
when Oracle => db_libs := db_lib1;
when Postgresql => db_libs := db_lib2;
when sqlserver => db_libs := db_lib3;
end case
then you can use db_libs and fill it up and use it like
ORACLE_HOME := external ("ORACLE_HOME", "ORACLE_HOME_not_set");
ORACLE_CLIENT := external ("ORACLE_CLIENT", "ORACLE_CLIENT_not_set");
ORA_INST := external ("ORACLE_INST", "ORACLE_INST_not_set");
LIB_SATTMATE := external ("SATTMATE_A", "SATTMATE_A_not_set");
....
there is also
Target_Machine : Environment.OS_Version_Type := Environment.Os_Version;
Compiler_Version : Environment.Compiler_Version_Type :=
Environment.Compiler_Version;
Data_Base : Environment.Database_Type := Environment.Database;
then it comes down to casing the correct combinations
case Target_Machine is
when "AIX_7.1" =>
case Database is
when "oracle_11" => db_libs :=
(SMT & "/global/sqlifc_oracle.o",
ORACLE_CLIENT & "/lib/libclntsh.a");
when "oci" => Data_Base_Libs :=
(ORACLE_CLIENT & "/lib/libclntsh.a",
SATTMATE_OCILIB & "/lib/libocilib.a");
when others => null;
end case;
Platform_Dependent_Compiler_Switches := ("-mminimal-toc") ;
Platform_Dependent_Linker_Switches := ("-L" & SMT & "/global",
LIB_SATTMATE,
"-Xlinker",
"-bhalt:5") & db_libs;
when "windows_6.2" =>
case Database is
when "oracle_11" => db_libs :=
(SMT & "/global/sqlifc_oracle.o",
ORA_INST & "/precomp/lib/oraSQL11.LIB");
when "oci" => db_libs :=
("-L" & ORACLE_CLIENT & "/bin",
"-loci",
"-L" & SATTMATE_OCILIB,
"-lociliba");
when "sqlserver" => db_libs := ("-lodbc32");
when others => null;
end case;
Platform_Dependent_Compiler_Switches := ("-gnatP");
Platform_Dependent_Linker_Switches :=
("-L" & SMT & "/global",
"-lsattmate") & db_libs;
when "linux-x64" => ....
when "linux-arm32" => ...
end case;
then use it like (the not previously shown varibles get values in other
case statemets)
package Compiler is
for Default_Switches ("Ada") use
Platform_Independent_Compiler_Switches &
Compiler_Dependent_Compiler_Switches &
Platform_Dependent_Compiler_Switches;
end Compiler;
package Linker is
for Default_Switches ("Ada") use Platform_Dependent_Linker_Switches;
end Linker;
Scenario variables are useful too to include a certain directory among
sources or not, like having common specs but os/db depedent bodies.
make directories win_x86, winx64,Linux_x64/mac/aix/whaterever and
include the correct one in Sources_dir
for Source_Dirs use common_dirs & (../win_x86);
--
Björn
^ permalink raw reply [flat|nested] 14+ messages in thread