1 |
2010/10/1 Fabian Groffen <grobian@g.o>: |
2 |
> On 01-10-2010 12:46:48 +0200, Al wrote: |
3 |
>> The parity compiler sounds very ambitious and I am curious. On the |
4 |
>> other hands I also see the advantages in Microsofts PATH approach. |
5 |
>> Dynamic libraries doen't depend on a special path any more and can be |
6 |
>> moved around. All you have to do, is to adapt the PATH variable to the |
7 |
>> new location. That makes your programs more portable. |
8 |
> |
9 |
> you have a wrong perception of portable to me |
10 |
|
11 |
It's not a wrong perception, it's a wider perception. In german it |
12 |
translates with: tragbar, transportabel, portabel. |
13 |
|
14 |
Here I use it in the sense of portablility inside one file system. |
15 |
Maybe you can find a better term. |
16 |
|
17 |
> |
18 |
>> What I am pondering on, is a relative RPATH, relative to the prefix |
19 |
>> path. By this the Prefix installation as a whole could still be moved |
20 |
>> around without breaking. You could run a precompiled PREFIX |
21 |
>> installation out of different user's home directories. |
22 |
> |
23 |
> You simply can't, because the libraries have paths hardcoded compiled |
24 |
> in. That is the whole reason why we decided to "fix" the paths where |
25 |
|
26 |
I know, however, I ponder. |
27 |
|
28 |
The prefix is a first step in that direction, Maybe, one can do the |
29 |
second step one day, but one can't do it all at once. |
30 |
|
31 |
> chpathtool exists for a reason, but still it's fragile, and won't work |
32 |
> on cygwin for sure. |
33 |
|
34 |
I'll take a look at that this evening. |
35 |
|
36 |
Al |