1 |
On 20/08/2005, at 11:25 PM, Grobian wrote: |
2 |
... |
3 |
> |
4 |
> Moral of the story: GNU is not Linux. Ehm, no. |
5 |
> - libedit appears to be a 'good enough' replacement for some tools, |
6 |
> good enough to make >=readline-4.1 applications compile |
7 |
> - libedit is in portage |
8 |
> - libedit is supplied with OSX |
9 |
> - libedit is even completer (with readline.h) supplied with Apple's |
10 |
> SDKs. |
11 |
> - there unfortunately is no virtual/readline in town, so emerging |
12 |
> libedit doesn't give you readline, while in fact it does. |
13 |
|
14 |
If libedit really is a complete replacement for readline (they |
15 |
provide the same functionality and at least compatible symlinks) then |
16 |
it should be a virtual. Currently the libedit ebuild doesn't install |
17 |
any compatibility symlinks or the headers, which means that on Gentoo |
18 |
they aren't really virtuals at the moment. |
19 |
|
20 |
Making them a virtual is probably a subject for broader discussion |
21 |
(making libedit install readline compatibility, make libedit/readline |
22 |
block and make them provide="virtual/readline"). |
23 |
|
24 |
> - assumming we would just lie some more to portage about what it |
25 |
> has and what it doesn't have, we would have to add the readline.h |
26 |
> file to /usr/include and make a package.provided. |
27 |
> |
28 |
|
29 |
(Because I don't know how this would be done) - where/how would we |
30 |
add readline.h to /usr/include? |
31 |
|
32 |
> I think all is dirty, but not being able to compile libxml because |
33 |
> the testing program -- which a regular user will never use -- uses |
34 |
> readline for its --shell mode which it doesn't even use in make |
35 |
> check stinks too. |
36 |
> |
37 |
|
38 |
Well making libedit/readline virtuals (if they really are) isn't |
39 |
dirty at all - it'd be the right solution. Not so sure about moving |
40 |
readline.h around... |
41 |
|
42 |
Regards, |
43 |
Mike |
44 |
|
45 |
|
46 |
-- |
47 |
gentoo-osx@g.o mailing list |