gtkada.gpr usage

gtkada.gpr usage

[ldries46]

Various times I tried after recommendation by others to include the "with 
gtkada statement in my project file (with GNAT programming studio)
Every time I do get error message like this:

gnatmake -d -PE:\ada\project\Algemeen\Algemeen.gpr -XLIBRARY_TYPE=static
Algemeen.adb -j4 -s
gnatbind -I- -x E:\ada\project\Algemeen\build\algemeen.ali
error: "gtk.ali" not found, "gtk.ads" must be compiled
error: "glib.ali" not found, "glib.adb" must be compiled
gnatmake: *** bind failed.

My GNAT GPS installation is on D:\Program files\GNAT\ 2012 and my
GtkADA installation is on D:\program files\GNAT\GtkADA
I do use GPR_PROJECT_PATH with the value D:\Program 
Files\2012\lib\gnat;D:\Program Files\GNAT\Gtkada\lib\gnat;
The files are present in the directory D:\Program 
Files\GNAT\Gtkada\lib\gnat.
What do I have to do to do not get this error. I already have installed 
GtkADA from the start, it didn't help.
Changing ../.. and .. by fully written file descriptions did not have any 
effect.

L. Dries 

Re: gtkada.gpr usage

[Dmitry A. Kazakov]

On Sun, 16 Dec 2012 14:45:14 +0100, ldries46 wrote:

> Various times I tried after recommendation by others to include the "with 
> gtkada statement in my project file (with GNAT programming studio)
> Every time I do get error message like this:
> 
> gnatmake -d -PE:\ada\project\Algemeen\Algemeen.gpr -XLIBRARY_TYPE=static
> Algemeen.adb -j4 -s
> gnatbind -I- -x E:\ada\project\Algemeen\build\algemeen.ali
> error: "gtk.ali" not found, "gtk.ads" must be compiled
> error: "glib.ali" not found, "glib.adb" must be compiled
> gnatmake: *** bind failed.

What happens when you link dynamically? It does not make much sense to link
GtkAda statically since Gtk is linked dynamically anyway. And static
linking to GtkAda posed problems in the past. 

> My GNAT GPS installation is on D:\Program files\GNAT\ 2012 and my
> GtkADA installation is on D:\program files\GNAT\GtkADA
> I do use GPR_PROJECT_PATH with the value D:\Program 
> Files\2012\lib\gnat;D:\Program Files\GNAT\Gtkada\lib\gnat;
> The files are present in the directory D:\Program 
> Files\GNAT\Gtkada\lib\gnat.

It is not the project path but missing compiled instances of GtkAda which
make trouble in your case. GtkAda (under Windows) is compiled when you
install it.

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

Re: gtkada.gpr usage

[ldries46]

I did again install the Gtkada library and saw that I got the following 
error in the detail window:
collect2: ld returned 1 exit status
gnatmake: gcc execution error
It was further told that the installation of the files was complete but the 
building of the libraries was not complete.
I therefor installed GPS again and got when reinstalling Gtkada the same 
error again.
Checked if the ali files were present in the lib/gnat directory and found 
they were present.
Changing static to relocatable in the gtkada.gpr file did not change the 
outcome
If I merge the gtkada.gpr with my own gpr and include the source directory 
of Gtkada the program is compiled coorectly.
So my problem stays what did I do wrong with original methode?

"Dmitry A. Kazakov"  schreef in bericht 
news:mjh9nsr3ncah$.1eq83ckmyzcwl.dlg@40tude.net...

On Sun, 16 Dec 2012 14:45:14 +0100, ldries46 wrote:

> Various times I tried after recommendation by others to include the "with
> gtkada statement in my project file (with GNAT programming studio)
> Every time I do get error message like this:
>
> gnatmake -d -PE:\ada\project\Algemeen\Algemeen.gpr -XLIBRARY_TYPE=static
> Algemeen.adb -j4 -s
> gnatbind -I- -x E:\ada\project\Algemeen\build\algemeen.ali
> error: "gtk.ali" not found, "gtk.ads" must be compiled
> error: "glib.ali" not found, "glib.adb" must be compiled
> gnatmake: *** bind failed.

What happens when you link dynamically? It does not make much sense to link
GtkAda statically since Gtk is linked dynamically anyway. And static
linking to GtkAda posed problems in the past.

> My GNAT GPS installation is on D:\Program files\GNAT\ 2012 and my
> GtkADA installation is on D:\program files\GNAT\GtkADA
> I do use GPR_PROJECT_PATH with the value D:\Program
> Files\2012\lib\gnat;D:\Program Files\GNAT\Gtkada\lib\gnat;
> The files are present in the directory D:\Program
> Files\GNAT\Gtkada\lib\gnat.

It is not the project path but missing compiled instances of GtkAda which
make trouble in your case. GtkAda (under Windows) is compiled when you
install it.

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

Re: gtkada.gpr usage

[Dmitry A. Kazakov]

On Mon, 17 Dec 2012 05:36:22 +0100, ldries46 wrote:

> If I merge the gtkada.gpr with my own gpr and include the source directory 
> of Gtkada the program is compiled coorectly.

Because in this case GtkAda is recompiled each time you build your project.

> So my problem stays what did I do wrong with original methode?

I would try to reinstall everything starting from GNAT. BTW, your paths
look strange. I didn't install GNAT GPL 2012, but all versions I used,
install under C:\GNAT and C:\GtkAda respectively rather than under
"D:\Program Files", which for a 64-bit system should be "D:\Program Files
(x86)". And why D:? are you using SSD to boot Windows? That does not work
well.

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

Re: gtkada.gpr usage

[ldries46]

I Think I have a good reason for doing so. I try to maintain order on my 
system, by only providing space for the system and some specials like Office 
programs on C:. All other programs I place on D: so I have a separation 
between system programs and user programs like f.i. GNAT Studio.
The E: partition is meant for data like the project directories for GNAT 
Studio use. F: I use for bulk data.
I also want pall programs on D:  in the program Files Directory and not for 
people who are not specialists arbitrary difference between two Program 
Files Directories. Now programs doing things in the same field can be found 
in the same Program Files directory (for instance Photoshop and some older 
graphic program like CD Labelprint.
This way the system is easier to maintain.

I have in the meantime first deleted both GPS and GtkADA for the disk and 
installed them bothagain. Now the compilation gives the same result as with 
the merged program files.

"Dmitry A. Kazakov"  schreef in bericht 
news:13zuzdvw7alhu$.yitnalafyje8$.dlg@40tude.net...

On Mon, 17 Dec 2012 05:36:22 +0100, ldries46 wrote:

> If I merge the gtkada.gpr with my own gpr and include the source directory
> of Gtkada the program is compiled coorectly.

Because in this case GtkAda is recompiled each time you build your project.

> So my problem stays what did I do wrong with original methode?

I would try to reinstall everything starting from GNAT. BTW, your paths
look strange. I didn't install GNAT GPL 2012, but all versions I used,
install under C:\GNAT and C:\GtkAda respectively rather than under
"D:\Program Files", which for a 64-bit system should be "D:\Program Files
(x86)". And why D:? are you using SSD to boot Windows? That does not work
well.

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

Re: gtkada.gpr usage

[J-P. Rosen]

Le 17/12/2012 09:28, Dmitry A. Kazakov a �crit :
> I would try to reinstall everything starting from GNAT. BTW, your paths
> look strange. I didn't install GNAT GPL 2012, but all versions I used,
> install under C:\GNAT and C:\GtkAda respectively rather than under
> "D:\Program Files", which for a 64-bit system should be "D:\Program Files
> (x86)". And why D:? are you using SSD to boot Windows? That does not work
> well.
I understand the desire to separate the locations for certain programs
(I do more or less the same), but why call it "Program Files" if you can
choose the name of the directory?

There are cases where tools (including some Gnat tools) have problems
with directory names that include spaces - this may be the origin of
your troubles. My own application directory is called "applic", and I
install under "Program Files" only if the installer proposes to do so,
otherwise I use "Applic". This strategy comes from experience and lot of
time wasted!

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: gtkada.gpr usage

[Randy Brukardt]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:kankbo$pes$1@dont-email.me...
...
> There are cases where tools (including some Gnat tools) have problems
> with directory names that include spaces - this may be the origin of
> your troubles. My own application directory is called "applic", and I
> install under "Program Files" only if the installer proposes to do so,
> otherwise I use "Applic". This strategy comes from experience and lot of
> time wasted!

On top of this, some programs refuse to install or work properly when not 
installed on C:. Such programs are broken, IMHO, but installing anywhere 
other than the default directory of the installer can be a crapshoot (no 
idea how well-tested alternative locations will be).

                                                  Randy.

Re: gtkada.gpr usage

[ldries46]

I indeed found the same problems with some programs, notably the problems 
with spaces (mostly some very old programs from the time that spaces were 
not yet allowed), programs which can only (partly) be installed on the C: 
partition.  It is my opinion that a neat system should be the first priority 
for also a programmer, even more for a Ada programmer, because neatness is 
one of the most important things that the Ada laguage forces on us.

"Randy Brukardt"  schreef in bericht news:kaocpl$un8$1@munin.nbi.dk...

"J-P. Rosen" <rosen@adalog.fr> wrote in message
news:kankbo$pes$1@dont-email.me...
...
> There are cases where tools (including some Gnat tools) have problems
> with directory names that include spaces - this may be the origin of
> your troubles. My own application directory is called "applic", and I
> install under "Program Files" only if the installer proposes to do so,
> otherwise I use "Applic". This strategy comes from experience and lot of
> time wasted!

On top of this, some programs refuse to install or work properly when not
installed on C:. Such programs are broken, IMHO, but installing anywhere
other than the default directory of the installer can be a crapshoot (no
idea how well-tested alternative locations will be).

                                                  Randy.