Bug 493214 – multilib-minimal.eclass enhancements

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Greg Turner 2013-12-03 11:37:15 UTC]

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

[Comment 1 Greg Turner 2013-12-03 11:38:14 UTC]

Created attachment 364510 [details, diff]
000-header.patch

de-headerization of eclass

[Comment 2 Greg Turner 2013-12-03 11:39:17 UTC]

Created attachment 364512 [details, diff]
001-debug-print-function.patch

some debug print boilerplate

[Comment 3 Greg Turner 2013-12-03 11:40:19 UTC]

Created attachment 364514 [details, diff]
002-MULTILIB_INSECURE_INSTALL.patch

adds a frob to globally disable automatic header checking and wrapping

[Comment 4 Greg Turner 2013-12-03 11:41:06 UTC]

Created attachment 364516 [details, diff]
003-in-source-doc.patch

Enhancements to the in-source documentation.

[Comment 5 Greg Turner 2013-12-03 11:41:51 UTC]

Created attachment 364518 [details, diff]
004-multilib-phase-all.patch

add _all callbacks for the other phases

[Comment 6 Greg Turner 2013-12-03 11:43:15 UTC]

Created attachment 364520 [details, diff]
005-MULTILIB_PARALLEL_PHASES.patch

Adds a frob to control parallelization of src_{configure,compile,test}

[Comment 7 Greg Turner 2013-12-03 11:44:03 UTC]

Created attachment 364522 [details, diff]
006-authors.patch

add an @Authors: tag with myself and mgorny

[Comment 8 Julian Ospald 2013-12-03 11:48:59 UTC]

these should be sent to gentoo dev ML

[Comment 9 Greg Turner 2013-12-03 12:11:32 UTC]

(In reply to Julian Ospald (hasufell) from comment #8)
> these should be sent to gentoo dev ML

ACK, will do.

[Comment 10 Julian Ospald 2013-12-11 18:35:54 UTC]

(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?

[Comment 11 Greg Turner 2013-12-11 20:44:17 UTC]

(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.

[Comment 12 Greg Turner 2013-12-11 20:59:50 UTC]

(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 [e-mail], and the list must silently drop mail from non-subscribers, as I sent as [e-mail].  Will try again as [e-mail] now.

[Comment 13 Greg Turner 2013-12-11 21:25:47 UTC]

(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.

[Comment 14 Julian Ospald 2013-12-27 21:50:03 UTC]

I think we can apply 001 at least, any objections from @multilib?

[Comment 15 Michał Górny 2013-12-27 22:41:38 UTC]

(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.

[Comment 16 Julian Ospald 2013-12-27 22:47:23 UTC]

+  27 Dec 2013; Julian Ospald <[e-mail]> multilib-minimal.eclass:
+  add debug print function wrt #493214
+

[Comment 17 Greg Turner 2013-12-28 09:54:41 UTC]

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

[Comment 18 Greg Turner 2014-05-31 09:46:03 UTC]

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.