1 |
Mike Frysinger wrote: |
2 |
> Steven J. Long wrote: |
3 |
> > Mike Frysinger wrote: |
4 |
> > > Steven J. Long wrote: |
5 |
> > > > The cross tools should NOT pollute the default PATH, simply because the |
6 |
> > > > user happened to run crossdev at some point. |
7 |
> > > |
8 |
> > > that's bs. people install crossdev to get a cross-compile environment, |
9 |
> > > not to get something that only works through `emerge`. attempting to |
10 |
> > > restrict it so it only works through `emerge` is unacceptable and it has |
11 |
> > > never been that way. |
12 |
> > |
13 |
> > That's why I suggested a small sh script to source, to setup that |
14 |
> > environment. Personally, I do an awful lot more than that just to build a |
15 |
> > native chroot, let alone cross-compile. And I really don't see the hardship |
16 |
> > for these brave "cross-compilers" of yours in sourcing a small setup |
17 |
> > script, which can be added to ~/.bashrc or even the system-wide one, for |
18 |
> > anyone who really wants it to apply whenever they login. Is this somehow |
19 |
> > beyond our most advanced userbase? |
20 |
> > |
21 |
> > People may install crossdev to get a cross-compile environment, but it's a |
22 |
> > broken design if it's not contained. |
23 |
> |
24 |
> your conclusions are invalid as you're basing them on the assumption that |
25 |
> the current multilib system is working correctly and cleanly. |
26 |
|
27 |
No, I am not. I am basing them on the premise that a "target" SYSROOT is |
28 |
potentially only one of N such sysroots for the same config.guess stanza. |
29 |
I expected you to see that usage immediately, and the flexibility that |
30 |
separation brings. After all, crossdev separates sysroots out already. It's |
31 |
a trivial change to keep them separate, and it's easy for cross-compilers, |
32 |
who already deal with this kind of thing, and more, on a daily basis. Only |
33 |
it gives them more options should they want them, as I for one do. |
34 |
|
35 |
No, use-cases are not relevant at this point. If you can't see it, that |
36 |
doesn't meant it's not out there; it just means you're looking in the |
37 |
wrong direction. |
38 |
|
39 |
> it is provably not. |
40 |
> |
41 |
> sticking your head in the sand and blaming crossdev for errors in the |
42 |
> multilib logic is asinine. |
43 |
|
44 |
And sticking your head in the sand and ignoring flexibility, is simply your |
45 |
usual ego-waving (as well as providing amusement at your rationalisation- |
46 |
masquerading-as-logic.) I'd hoped you'd grown past this in the last few years, |
47 |
since the embarrassing (to you) eclass-manpages awk bug, but evidently not. |
48 |
It's why you're an awful recruiter, and imo a useless coder, despite being |
49 |
a very talented QA person and bug-patcher. |
50 |
|
51 |
The more you code, the more you have to realise how susceptible you are to |
52 |
mistake. It's *after* you fully realise and _accept_ that, that you become |
53 |
a truly useful coder. You are clearly still at the wrestling-with-the-ego |
54 |
stage, after all these years. So you have my sympathy, because I know how |
55 |
difficult a fight that is, and you're clearly in distress (or you wouldn't |
56 |
resort to negative personal attacks so frequently, instead of considering |
57 |
the application. So much bile..) The way to win is to stop fighting, |
58 |
because you are only fighting yourself. |
59 |
|
60 |
Accept that you are only a human, and you make mistakes and have blind-spots |
61 |
just like everyone else. One's just been pointed out to you; do you do the |
62 |
grown-up thing and accept that, and fix it, or do you keep on with the |
63 |
tantrums, the dodgy patches and the baroque chain of "fixes" that flow from |
64 |
your borked "logic"? Grow up, already. Or fire off more bile > /dev/null. |
65 |
|
66 |
"I'll see you when you get there, if you ever get there.." |
67 |
|
68 |
-- |
69 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |