| 1 |
On Thu, 2015-12-03 at 09:28 +0100, Alexis Ballier wrote: |
| 2 |
> On Wed, 2 Dec 2015 23:20:05 +0000 |
| 3 |
> James Le Cuirot <chewi@g.o> wrote: |
| 4 |
> |
| 5 |
> > On Wed, 2 Dec 2015 12:40:08 +0100 |
| 6 |
> > Alexis Ballier <aballier@g.o> wrote: |
| 7 |
> > |
| 8 |
> > > On Tue, 1 Dec 2015 22:58:55 +0000 |
| 9 |
> > > James Le Cuirot <chewi@g.o> wrote: |
| 10 |
> > > [...] |
| 11 |
> > > > |
| 12 |
> > > > I raised one further point with mgorny that he feels could |
| 13 |
> > > > potentially go into EAPI 7 but I think could remain an |
| 14 |
> > > > implementation detail. In cases #3 and #4 (basically when |
| 15 |
> > > > ROOT != / and PORTAGE_CONFIGROOT != /), the toolchain needs to |
| 16 |
> > > > know how to source headers and libraries from ROOT instead of /. |
| 17 |
> > > |
| 18 |
> > > Use SYSROOT. ROOT has nothing to do with building. This should be |
| 19 |
> > > defined in PMS though. |
| 20 |
> > |
| 21 |
> > In case #2, ROOT != / but SYSROOT = / so I take your point that |
| 22 |
> > SYSROOT would negate the need to check which use case we're dealing |
| 23 |
> > with. |
| 24 |
> > |
| 25 |
> > I looked into SYSROOT while I was writing cross-boss. It's used in |
| 26 |
> > some crossdev scripts, most notably cross-pkg-config, but not by |
| 27 |
> > pkg-config itself. It's also used in a small handful of eclasses and |
| 28 |
> > other *-config scripts but that's all. Conversely, the aforementioned |
| 29 |
> > libtool patch uses ROOT and I suspect many other things do too. In |
| 30 |
> > practise, you need to set both. |
| 31 |
> |
| 32 |
> The libtool patch has probably not been updated after SYSROOT |
| 33 |
> introduction. Feel free to file a bug about it. |
| 34 |
> |
| 35 |
> > On reflection, I'm now thinking that we should call it something less |
| 36 |
> > generic. I also found that the Qt build uses SYSROOT for its own |
| 37 |
> > purposes so you cannot rely on it in toolchain wrappers. ROOT is |
| 38 |
> > probably just as unreliable. For that reason, I ended up using |
| 39 |
> > CB_SYSROOT in cross-boss. |
| 40 |
> > |
| 41 |
> > I forgot to mention earlier that if ROOT were used, PMS actually |
| 42 |
> > forbids it from being referenced in the src_* phases so this |
| 43 |
> > restriction would need to be lifted. Relying on the toolchain's |
| 44 |
> > internal sysroot is not sufficient. |
| 45 |
> |
| 46 |
> And PMS is absolutely right. |
| 47 |
> |
| 48 |
> Put simple: |
| 49 |
> SYSROOT is where "sources" are installed (headers, .so, etc); think |
| 50 |
> debian's -dev packages. |
| 51 |
> ROOT is where packages are merged. |
| 52 |
> |
| 53 |
> Meaning: |
| 54 |
> |
| 55 |
> RDEPEND are installed to ROOT |
| 56 |
> DEPEND are installed to SYSROOT |
| 57 |
|
| 58 |
hmm, this implies that a pkg in both DEPEND and RDEPEND should be installed in both |
| 59 |
SYSROOT and ROOT? Does portage do this ATM? |
| 60 |
|
| 61 |
|
| 62 |
> (BDEPEND are installed to /) |
Archives