eqmake4 should be split into a utility eclass The current design of qt4-r2 causes random phase overrides and uses base.eclass by default which many devs do not like at all. Some eclasses are already dropping base.eclass inherit to favor the PMS specified behavior. Currently I am overriding all such phases I don't want being overridden by base.eclas, as in: src_unpack() { default; } that *****. The only reason I use qt4-r2 is because of the eqmake4 function, please split it (probably along with the "_find_project_file" function).
@pesa, what do you think? IIRC, you did such split in qt overlay. Is it ready to hit main tree?
We are already working towards this, see qmake-utils.eclass in qt overlay (contains both eqmake4 and eqmake5). We could move it to the main tree I think, reviews are appreciated.
Will we keep the eqmake code in both eclasses, or have qt4-r2 inherit qmake-utils?
(In reply to Michael Palimaka (kensington) from comment #3) > Will we keep the eqmake code in both eclasses, or have qt4-r2 inherit > qmake-utils? code duplication is not good
(In reply to Julian Ospald (hasufell) from comment #4) > (In reply to Michael Palimaka (kensington) from comment #3) > > Will we keep the eqmake code in both eclasses, or have qt4-r2 inherit > > qmake-utils? > > code duplication is not good I know, but it never hurts to explore all options, someone may think of an issue others did not.
(In reply to Michael Palimaka (kensington) from comment #3) > Will we keep the eqmake code in both eclasses, or have qt4-r2 inherit > qmake-utils? I think about the latter. The first seems strange to me
(In reply to Michael Palimaka (kensington) from comment #3) > Will we keep the eqmake code in both eclasses, or have qt4-r2 inherit > qmake-utils? I'm more inclined towards the latter, although that would mean exposing eqmake5() to qt4-r2 consumers...
how is it going?
I will take care of this as soon as I get back from my devaway (2nd half of October hopefully)
qmake-utils.eclass is now in tree (thanks pinkbyte!)
thanks
