On 04.08.2010 16:55, Ulrich Weigand wrote:
Matthias Klosedoko@ubuntu.com wrote on 08/02/2010 09:38:49 PM:
On 02.08.2010 21:12, Ulrich Weigand wrote:
Matthias Klosedoko@ubuntu.com wrote on 08/02/2010 06:25:58 PM: So the problem that is you want to support a setup where a "gcc" driver installed from a 4.4.4 build can still call and run a "gnat1" binary installed from a 4.4.3 build? That will most likely work.
No, gnat (4.4.3) has still to work, if gcc (4.4.4) is already installed.
OK, where I said "gcc", the same applies also for "gnat", the Ada compiler driver. The reason for why a 4.4.3 gnat would fail if 4.4.4 gcc is installed is that it wouldn't find things like collect2, libgcc, crt*.o etc. Right?
yes
But it still seems a bit fragile to me; in general, there's no
guarantee
that if you intermix 4.4.4 and 4.4.3 components in that way, everything actually works (that's why they use different directories in the first place).
Then I would need to change this internal path with every source change.
I
don't see this as fragile as long as it is ensured that we ship with the different frontends built from the same patchsets/sources. Note that
further
restrictions are made by package dependencies.
The issues I'm thinking of are things like: suppose the 4.4.4 middle-end adds code that generates calls to some new libgcc library function, which itself was added with the 4.4.4 libgcc. If you now mix-and-match components so that a compiler built from the 4.4.4 sources and using the new middle-end is used together with a libgcc built from the 4.4.3 sources, things will break.
libgcc is always built from the sources which get uploaded first.
It seems that this does not actually occur in the usage model you describe, since you apparently always update the core (libgcc etc.) *first*. I'm not sure if this is actually guaranteed by the package dependencies though. If it is, then I don't see any real problems with that approach ...
If you want to have separate packages, a cleaner way would appear to be
to
make them fully self-contained, e.g. have them each provide their own driver that can be called separately.
I don't understand that. I don't have a problem with the driver, butwith
the
compiler (gnat1). Having the packages self-contained creates another problem in that you get file conflicts for files like collect2, various .o files
etc.
What I was thinking of is along the lines of having gcc-base-4.4.3 and gcc-base-4.4.4 packages that hold the base files (crt*o, libgcc, collect2 ...), such that you can install *multiple* of the base packages at the same time. This way you could have a gcc-4.4.4 (depending on gcc-base-4.4.4) and a gnat-4.4.3 (depending on gcc-base-4.4.3) all installed at the same time.
sure, you could have separate packages for subminor versions, and introduce a new dependency package for the minor version (gcc-4.4-defaults), but I don't see how this would help within the context of the distribution.
Matthias