Bug includes broken-out patchlist for various enhancements in my tree. The enclosed patches, applied in series, take eclass/multilib-minimal.eclass from the current gentoo-x86 version up to that found in my overlay at: http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=blob;f=eclass/multilib-minimal.eclass;h=50b301563fed0d477e307e2318135170951e0225;hb=HEAD Reproducible: Always
Created attachment 364510 [details, diff] 000-header.patch de-headerization of eclass
Created attachment 364512 [details, diff] 001-debug-print-function.patch some debug print boilerplate
Created attachment 364514 [details, diff] 002-MULTILIB_INSECURE_INSTALL.patch adds a frob to globally disable automatic header checking and wrapping
Created attachment 364516 [details, diff] 003-in-source-doc.patch Enhancements to the in-source documentation.
Created attachment 364518 [details, diff] 004-multilib-phase-all.patch add _all callbacks for the other phases
Created attachment 364520 [details, diff] 005-MULTILIB_PARALLEL_PHASES.patch Adds a frob to control parallelization of src_{configure,compile,test}
Created attachment 364522 [details, diff] 006-authors.patch add an @Authors: tag with myself and mgorny
these should be sent to gentoo dev ML
(In reply to Julian Ospald (hasufell) from comment #8) > these should be sent to gentoo dev ML ACK, will do.
(In reply to Greg Turner from comment #9) > (In reply to Julian Ospald (hasufell) from comment #8) > > these should be sent to gentoo dev ML > > ACK, will do. when?
(In reply to Julian Ospald (hasufell) from comment #10) > (In reply to Greg Turner from comment #9) > > (In reply to Julian Ospald (hasufell) from comment #8) > > > these should be sent to gentoo dev ML > > > > ACK, will do. > > when? I thought I sent them out some days ago... looking into what happened.
(In reply to Greg Turner from comment #11) > (In reply to Julian Ospald (hasufell) from comment #10) > > (In reply to Greg Turner from comment #9) > > > (In reply to Julian Ospald (hasufell) from comment #8) > > > > these should be sent to gentoo dev ML > > > > > > ACK, will do. > > > > when? > > I thought I sent them out some days ago... looking into what happened. I guess, I must be subscribed to the list as gmt@malth.us, and the list must silently drop mail from non-subscribers, as I sent as gmt@be-evil.net. Will try again as gmt@malth.us now.
(In reply to Julian Ospald (hasufell) from comment #10) > (In reply to Greg Turner from comment #9) > > (In reply to Julian Ospald (hasufell) from comment #8) > > > these should be sent to gentoo dev ML > > > > ACK, will do. > > when? Resent, and, this time, confirmed that they showed up on gmane.
I think we can apply 001 at least, any objections from @multilib?
(In reply to Julian Ospald (hasufell) from comment #14) > I think we can apply 001 at least, any objections from @multilib? Yes, 001 seems completely fine. Not really convinced about any of the others.
+ 27 Dec 2013; Julian Ospald <hasufell@gentoo.org> multilib-minimal.eclass: + add debug print function wrt #493214 +
I need to iterate on 002 and 003. 004 seems to be destined for the rubbish heap 005. ?... Something needs to be done about it -- the status quo, last I checked, was automatic, mandatory src_configure parallel-ization. I can't imagine that's what people want. At some point, I feel, we ought to have a flame war (a civilized technical debate might also suffice :)) about the merits of supporting, vs. not supporting, src_compile parallelization. Note, however, that fixing of src_configure parallelization to be non-mandatory does not require doing anything to any other phases. I'd hate to create a false contingency, there, with paradoxical detrimental effect to the framework. I'll try not to do that if possible; for a start, I'll see if I can't stimulate some conversation about it on gentoo-dev after the weekend (too much afk 'till then). So my to-do list seems to be: Rev 002 (Already done, just need to backport). Rev 003 (not done, but I have pretty clear marching orders). start flame-war about src_compile parallelization on Monday
Too much drift has happened, and most of the interesting parts have been either rejected or completely revamped in my tree (or both :)). Closing as obsolete.
