Summary: | gnome2-multilib.eclass: add an eclass for native multilib support | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | multilib+disabled |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 454644, 469180, 474364, 488608 |
Description
Pacho Ramos
2013-07-23 20:24:30 UTC
Can we fold this into gnome3.eclass with PATCHES support etc.? I wouldn't block this by gnome3.eclass effort (it will include much more changes, like also the GCONF_DEBUG stuff, using autotools-utils.eclass if possible, drop G2CONF...), while this one is much more simple We can commit this and, once we have a gnome3.eclass, let it also be multilib happy. Otherwise, we will probably end delaying so too much (as usually occurs in long standing eclass issues :S) Guys, if you are willing to write a new eclass, just go ahead and have it reviewed. I'm more inclined to have our current one evolve. It is a slow path because we need to be considerate about the impact of each changes but this is the way for all eclasses the day they are commited to the tree. So please, if you have ideas, I'd rather you file a bug report with a clearly written grief against current eclass, what behavior your would like to see to fix it and move on from there. The major obstacle until now to all non-trivial changes as always been the "get together to have a clear picture and decide something". Having a gnome3.eclass is going to send the wrong signal imho, things haven't changed as much as the name would say. Then, better discuss it in a different bug... maybe we need to review the old eclass tracker Could anyone review the eclass commented in comment#0? Thanks (I guess we would need to send it to gentoo-dev ML too) @Pacho, please consider using multilib-minimal since that people will most likely use to override the phases. I'm probably going to transform autotools-multilib as a wrapped to that as well. @Michal, I guess it should go similar to netsurf.eclass then... but I don't fully understand the advantage of adding another layer (multilib-minimal) here :/ (In reply to Pacho Ramos from comment #7) > @Michal, I guess it should go similar to netsurf.eclass then... but I don't > fully understand the advantage of adding another layer (multilib-minimal) > here :/ Say, you want to add another thing to be done in multilib_src_compile(). It's a bit about: src_compile() { gnome2-multilib_src_compile func() { ... } multilib_foreach_abi func } or: src_compile() { func() { gnome2_src_compile ... } multilib_foreach_abi func } vs: multilib_src_compile() { gnome2_src_compile ... } I hit similar issues when converting stuff to autotools-multilib. Ah, ok :) I'm honestly not convinced that we want this. I'd just do multilib-minimal w/ proper gnome function calls... (In reply to Michał Górny from comment #10) > I'm honestly not convinced that we want this. I'd just do multilib-minimal > w/ proper gnome function calls... Looks like that is the way that was followed and, well, doesn't look so bad to me as I thought before. Sorry for the noise ;) |