[gnuada, question] installations directory

[gnuada, question] installations directory

[Martin Krischik]

Hello

currently the GNU Ada projects uses /opt/gnat as installation directory.
However it has been observed that this means on can only install one gnat
at a time.

We could - just like GNAT/Pro on Windows - install each GNAT into a separate
directory.

----

Option 1 (leave as is)

/opt/gnat


Option 2 (just the types):

/opt/gnat/gpl
/opt/gnat/gcc

Disadvantage: you can still only configure one system in /etc/profile.d and 
/etc/ld.so.conf.d.

Option 3 (inc. version);

/opt/gnat/gpl/2005
/opt/gnat/gcc/3.4.5
/opt/gnat/gcc/4.0.2

Disadvantage: What should "rpm --upgrade" do? Probably not what half the
users would expect.

-----

Personally I think option 2 might be a good alternative. I am very unsure
about option 3 as it is totally against the rpm concept and might therefore
lead to all sorts of problems.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [gnuada, question] installations directory

[Georg Bauhaus]

Martin Krischik wrote:
> Hello
> 
> currently the GNU Ada projects uses /opt/gnat as installation directory.
> However it has been observed that this means on can only install one gnat
> at a time.
> 
> We could - just like GNAT/Pro on Windows - install each GNAT into a separate
> directory.

Multiple Apple GCCs can be installed and used together,
there is a "switching program" (gcc_select IIRC).

Or, isn't there an rpm option to install in separate
installation roots?

-- Georg 

Re: [gnuada, question] installations directory

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik wrote:
>> Hello
>> 
>> currently the GNU Ada projects uses /opt/gnat as installation directory.
>> However it has been observed that this means on can only install one gnat
>> at a time.
>> 
>> We could - just like GNAT/Pro on Windows - install each GNAT into a
>> separate directory.
> 
> Multiple Apple GCCs can be installed and used together,
> there is a "switching program" (gcc_select IIRC).

Linux is still not quite as easy to use as Mac :-(. Multiple gcc are not
usually available on Linux.

> Or, isn't there an rpm option to install in separate
> installation roots?

Yes there is. The problem is the search path for DLLs. The path of an DLL is
hard-coded into the executable. There is also an additional search which
can be set in /etc/ld.so.conf.d when the DLL is not found at the "usual"
place.

But that is all manual extra installation and can be quite tricky - nothing
I would want dump on an unwary beginner of Ada.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [gnuada, question] installations directory

[Larry Kilgallen]

In article <32492718.GlmySslk4r@linux1.krischik.com>, Martin Krischik <krischik@users.sourceforge.net> writes:
> Georg Bauhaus wrote:

>> Or, isn't there an rpm option to install in separate
>> installation roots?
> 
> Yes there is. The problem is the search path for DLLs. The path of an DLL is
> hard-coded into the executable. There is also an additional search which
> can be set in /etc/ld.so.conf.d when the DLL is not found at the "usual"
> place.

The VMS equivalent tools have a command procedure to "choose which
version of <product-name> you want" and that command procedure defines
logical names where shareable images (similar to DLLs I think) can
be found.  The name inside the image points to the shareable image
via the logical name.

> But that is all manual extra installation and can be quite tricky - nothing
> I would want dump on an unwary beginner of Ada.

How about having the default method point to the "standard place"?
Those unwary beginners do not care about multiple versions.

Re: [gnuada, question] installations directory

[Martin Krischik]

Larry Kilgallen wrote:

> In article <32492718.GlmySslk4r@linux1.krischik.com>, Martin Krischik
> <krischik@users.sourceforge.net> writes:
>> Georg Bauhaus wrote:
> 
>>> Or, isn't there an rpm option to install in separate
>>> installation roots?
>> 
>> Yes there is. The problem is the search path for DLLs. The path of an DLL
>> is hard-coded into the executable. There is also an additional search
>> which can be set in /etc/ld.so.conf.d when the DLL is not found at the
>> "usual" place.
> 
> The VMS equivalent tools have a command procedure to "choose which
> version of <product-name> you want" and that command procedure defines
> logical names where shareable images (similar to DLLs I think) can
> be found.  The name inside the image points to the shareable image
> via the logical name.
> 
>> But that is all manual extra installation and can be quite tricky -
>> nothing I would want dump on an unwary beginner of Ada.
> 
> How about having the default method point to the "standard place"?
> Those unwary beginners do not care about multiple versions.

I have had a look around. With rpm you can create "relocatable packages"
which are then installed with

rpm --install --prefix=/wherever/you/want/it

Of corse there is a default for --prefix for the unwary beginners.  I think
we should have the packages "relocatable" - actually they are allready -
just I never tested it.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [gnuada, question] installations directory

[Ludovic Brenta]

Martin Krischik <krischik@users.sourceforge.net> writes:
> Linux is still not quite as easy to use as Mac :-(. Multiple gcc are not
> usually available on Linux.

GCC is designed so that multiple versions of it can be on the same
system.  This is especially imortant when you want both native and
cross compilers to be available.  Look at gcc -B, and the directory
structure: /usr/lib/gcc/<target>/<version>/gnat1

>> Or, isn't there an rpm option to install in separate
>> installation roots?
>
> Yes there is. The problem is the search path for DLLs. The path of an DLL is
> hard-coded into the executable.

Only if the shared library is created with "rpath", which is against
Debian policy for example.  rpath is a linker option.

It is quite easy to have multiple versions of libgnat installed,
provided they have different sonames.

> There is also an additional search which can be set in
> /etc/ld.so.conf.d when the DLL is not found at the "usual" place.

> But that is all manual extra installation and can be quite tricky -
> nothing I would want dump on an unwary beginner of Ada.

The packages should use GCC's directory structure, and rename "gcc" to
"gcc-3.4" or "gcc-4.0" as Debian does.  Then one symlink, gcc, points
to the system's default version.  With gnat, the tools (gnatmake,
gnatlink etc.) can be symlinks (in /usr/bin) pointing to executables
in /usr/lib/gcc/<target>/<version>.

-- 
Ludovic Brenta.

Re: [gnuada, question] installations directory

[Larry Kilgallen]

In article <1150472.HIHOOy7jJt@linux1.krischik.com>, Martin Krischik <krischik@users.sourceforge.net> writes:

> We could - just like GNAT/Pro on Windows - install each GNAT into a separate
> directory.
> 
> ----
> 
> Option 1 (leave as is)
> 
> /opt/gnat
> 
> 
> Option 2 (just the types):
> 
> /opt/gnat/gpl
> /opt/gnat/gcc
> 
> Disadvantage: you can still only configure one system in /etc/profile.d and 
> /etc/ld.so.conf.d.
> 
> Option 3 (inc. version);
> 
> /opt/gnat/gpl/2005
> /opt/gnat/gcc/3.4.5
> /opt/gnat/gcc/4.0.2
> 
> Disadvantage: What should "rpm --upgrade" do? Probably not what half the
> users would expect.

I don't speak Unix, but several VMS products have the informal ability
to have side versions and also the main version.  The main version is
the one in a less-adorned directory name and is the one that gets updated.

You could probably apply that technique to Unix-land, letting the customer
put individual versions in their correspondingly-named directories and
also put one of those versions in a generally-named directory.  You could
even have the installation procedure readily do a parallel installation
into a correspondingly-named directory when installing into the generally-
named directory.

Re: [gnuada, question] installations directory

[Martin Krischik]

Larry Kilgallen wrote:

> In article <1150472.HIHOOy7jJt@linux1.krischik.com>, Martin Krischik
> <krischik@users.sourceforge.net> writes:
> 
>> We could - just like GNAT/Pro on Windows - install each GNAT into a
>> separate directory.
>> 
>> ----
>> 
>> Option 1 (leave as is)
>> 
>> /opt/gnat
>> 
>> 
>> Option 2 (just the types):
>> 
>> /opt/gnat/gpl
>> /opt/gnat/gcc
>> 
>> Disadvantage: you can still only configure one system in /etc/profile.d
>> and /etc/ld.so.conf.d.
>> 
>> Option 3 (inc. version);
>> 
>> /opt/gnat/gpl/2005
>> /opt/gnat/gcc/3.4.5
>> /opt/gnat/gcc/4.0.2
>> 
>> Disadvantage: What should "rpm --upgrade" do? Probably not what half the
>> users would expect.
> 
> I don't speak Unix, but several VMS products have the informal ability
> to have side versions and also the main version.  The main version is
> the one in a less-adorned directory name and is the one that gets updated.

Which the Red-Had-Packagemanager has not got - hence the question.

> You could probably apply that technique to Unix-land, letting the customer
> put individual versions in their correspondingly-named directories and
> also put one of those versions in a generally-named directory.  You could
> even have the installation procedure readily do a parallel installation
> into a correspondingly-named directory when installing into the generally-
> named directory.

Only if every version becomes a package of it's own right. But if every
version is a package and vice versa you can't do any upgrades.

Perhaps to much work for to little gain.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [gnuada, question] installations directory

[Jeffrey Creem]

Martin Krischik wrote:
> Hello
> 
> currently the GNU Ada projects uses /opt/gnat as installation directory.
> However it has been observed that this means on can only install one gnat
> at a time.
> 
> We could - just like GNAT/Pro on Windows - install each GNAT into a separate
> directory.
> 
> ----
> 
> Option 1 (leave as is)
> 
> /opt/gnat
> 
> 
> Option 2 (just the types):
> 
> /opt/gnat/gpl
> /opt/gnat/gcc
> 
> Disadvantage: you can still only configure one system in /etc/profile.d and 
> /etc/ld.so.conf.d.
> 
> Option 3 (inc. version);
> 
> /opt/gnat/gpl/2005
> /opt/gnat/gcc/3.4.5
> /opt/gnat/gcc/4.0.2
> 
> Disadvantage: What should "rpm --upgrade" do? Probably not what half the
> users would expect.
> 
> -----
> 
> Personally I think option 2 might be a good alternative. I am very unsure
> about option 3 as it is totally against the rpm concept and might therefore
> lead to all sorts of problems.
> 
> Martin

I think this concept is a bit like one of the other posters suggested.

In a perfect world, we would do something like

/opt/gnat/gpl
/opt/gnat/gcc

Each designed to hold the "latest" version of its flavor.

(which is sort of like option 2).

Then if the developers were really kind, we could also add something
like

/opt/gnat/locked/gcc/3.4.5
/opt/gnat/locked/gcc/4.0.2
/opt/gnat/locked/gpl/2005

(perhaps replaced locked with a better term if we can think of one).

The top leve (non-locked) would be for the mainline releases/upgrades of 
the compiler.

The ones under "locked" would only be rpm --upgradeable if we were to 
find some sort of packaging issue that required us to release a new RPM 
(e.g. a patch to something like 4.0.2 RPm to add a missing file or 
perhaps other local patches)

Of course this whole thing could get carried away in terms of the level 
of effort required for a community development.

I know for things like the sparc solaris .pkg I uploaded it takes more 
than a day to build on my old dog sparc.

The biggest problem with these multiple compiler (and other future 
component)  versions are the shared libraries. They are a real pain and 
will inevitably lead to user confusion...

Re: [gnuada, question] installations directory

[Martin Krischik]

Jeffrey Creem wrote:

> Martin Krischik wrote:
>> Hello
>> 
>> currently the GNU Ada projects uses /opt/gnat as installation directory.
>> However it has been observed that this means on can only install one gnat
>> at a time.
>> 
>> We could - just like GNAT/Pro on Windows - install each GNAT into a
>> separate directory.
>> 
>> ----
>> 
>> Option 1 (leave as is)
>> 
>> /opt/gnat
>> 
>> 
>> Option 2 (just the types):
>> 
>> /opt/gnat/gpl
>> /opt/gnat/gcc
>> 
>> Disadvantage: you can still only configure one system in /etc/profile.d
>> and /etc/ld.so.conf.d.
>> 
>> Option 3 (inc. version);
>> 
>> /opt/gnat/gpl/2005
>> /opt/gnat/gcc/3.4.5
>> /opt/gnat/gcc/4.0.2
>> 
>> Disadvantage: What should "rpm --upgrade" do? Probably not what half the
>> users would expect.
>> 
>> -----
>> 
>> Personally I think option 2 might be a good alternative. I am very unsure
>> about option 3 as it is totally against the rpm concept and might
>> therefore lead to all sorts of problems.
>> 
>> Martin
> 
> I think this concept is a bit like one of the other posters suggested.
> 
> In a perfect world, we would do something like
> 
> /opt/gnat/gpl
> /opt/gnat/gcc
> 
> Each designed to hold the "latest" version of its flavor.
> 
> (which is sort of like option 2).
> 
> Then if the developers were really kind, we could also add something
> like
> 
> /opt/gnat/locked/gcc/3.4.5
> /opt/gnat/locked/gcc/4.0.2
> /opt/gnat/locked/gpl/2005
> 
> (perhaps replaced locked with a better term if we can think of one).
> 
> The top leve (non-locked) would be for the mainline releases/upgrades of
> the compiler.
> 
> The ones under "locked" would only be rpm --upgradeable if we were to
> find some sort of packaging issue that required us to release a new RPM
> (e.g. a patch to something like 4.0.2 RPm to add a missing file or
> perhaps other local patches)
> 
> Of course this whole thing could get carried away in terms of the level
> of effort required for a community development.

That is my thinking as well. While option 2 could be done with a "one off" 
of 1 hour attended and about 24 hours unattended option 3 would lead to a
constant extra effort.

> The biggest problem with these multiple compiler (and other future
> component)  versions are the shared libraries. They are a real pain and
> will inevitably lead to user confusion...

That is another point. While at work we do use option 3 for vms and Linux we
(not me - someone else ;-) ) get paid for the effort of creating and
maintaining all the versions - but for comunity package I am not sure if it
is worth the effort.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [gnuada, question] installations directory

[Martin Krischik]

Jeffrey Creem wrote:

> The biggest problem with these multiple compiler (and other future
> component) ï¿œversions are the shared libraries. They are a real pain and
> will inevitably lead to user confusion...

One more thing:

We should not forget the "future components" part. If you look at the
download page you will see quite a few of them.

1) Without a propper "rpm --upgrade" keeping such a system in sync might
quickly become difficult.

2) also the user might be tempted to mix and match - which will not work for
example with ASIS.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [gnuada, question] installations directory

[Simon Wright]

Jeffrey Creem <jeff@thecreems.com> writes:

> The biggest problem with these multiple compiler (and other future
> component) versions are the shared libraries. They are a real pain
> and will inevitably lead to user confusion...

Yes, indeed, so why is everyone so keen to use them? GNAT works just
fine with minimal front-ending (http://www.pushface.org/gnatfe/) on
all the Unix-based systems I know of; on my Mandrake box I have 5
different GNATs, on this Mac I have 3 (including a homebrewed 4.0.0
and GNAT GPL).

Re: installations directory

[krischik]

Hi Simon,

Is it difficult to produce installation packages for mandriva linux or
Mac?

Besides: I have the feeling that most users who have wish for multiple
installations compile there own anyway.

But I still consider:

/opt/gnat/gpl
/opt/gnat/gcc
/opt/gnat/pro

as it has a good relation between extra effort and extra features
gained.

Martin

Re: installations directory

[Simon Wright]

"krischik" <krischik@users.sourceforge.net> writes:

> Is it difficult to produce installation packages for mandriva linux or
> Mac?

Mandrake is RedHat based & uses RPMs. But I'm not up with the latest
(I tend to upgrade OS when I buy a new box!).

For MacOS, there's a team who implement GNAT Ada integrated with the
XCode development system; I built my own 4.0.0 which comes in at 33 MB
(.tar.gz), they are running at 4.01 (they say, I don't know what that
actually corresponds to!). http://www.macada.org/

> Besides: I have the feeling that most users who have wish for multiple
> installations compile there own anyway.
>
> But I still consider:
>
> /opt/gnat/gpl
> /opt/gnat/gcc
> /opt/gnat/pro
>
> as it has a good relation between extra effort and extra features
> gained.

Yes, seems sensible. I use eg

  /opt/4.0.0
  /opt/gnat-gpl-2005

but that's purely ny convention, nothing special to recommend it and
yours has the strong advantage of actually mentioning GNAT!

Re: installations directory

[Martin Krischik]

Simon Wright wrote:

> "krischik" <krischik@users.sourceforge.net> writes:
> 
>> Is it difficult to produce installation packages for mandriva linux or
>> Mac?
> 
> Mandrake is RedHat based & uses RPMs. But I'm not up with the latest
> (I tend to upgrade OS when I buy a new box!).

Well, we have SuSE 10.0 and SuSE 9.2 as well. The rpm specs are now pretty
good (running right now) so with a bit of luck all that is needed is some:

rpmbuild -ba gnat-gpl-2005.spec

to create a package. And replace "SuSE_X_X" with "Mandrake_X_X" to
the .rpmmacros file.

But wait a week - I am working on the r2 release - with multiple gnat
installation. Has some advantage for package maintainer as well: I can
create Library packages for more then one GNAT.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com