I've had this kicking around in my local overlay for some time but, now that I have a solution the IMAP problem that I'm happy with - and entails the use of custom makeopts as is needed here - now is a good a time as any to pass it on. I'll merely describe the changes as, if I produce a patch, it will conflict with the IMAP support patch I've attached to bug 308561 (which is worth looking at first). Essentially, it goes like this where "..." is used as shorthand for all existing code leading up to - or following from - my changes: src_configure() { ... # Custom menuselect options are defined in this file (it may remain empty) # >"${S}"/gentoo.makeopts if use_debug; then local debug_opts="DEBUG_CHANNEL_LOCKS DEBUG_THREADS DEBUG_FD_LEAKS" einfo "Enabling debugging options: ${debug_opts}" echo "MENUSELECT_CFLAGS=${debug_opts}" >> "${S}"/gentoo.makeopts fi } ... src_configure() { if use debug; then # Tone down the compiler flags somewhat. This should be less aggressive # than the DONT_OPTIMIZE option whilst still producing useful results. # strip-flags replace-flags -O? -O0 fi .... } src_compile() { ASTLDFLAGS="${LDFLAGS}" emake USER_MAKEOPTS="${S}"/gentoo.makeopts || die "emake failed" } And there you have it. USE="debug" will now build asterisk in a fashion conducive to debugging.
Copying in Jaco so as to court his opinion ...
The courted likes. What's the difference between -O0 and DONT_OPTIMIZE? There is one more thing we can consider - having a way of passing arbitrary .makeopts stuff - but then again - I believe we ripped that out not too long ago? (because the method wasn't clean, nor do I see a clean way of dealing with this) Would make it easier to play with ideas such as res_ais though ... (which you can get btw by simply installing openais before asterisk - which IMHO also violates some ebuild principles).
> What's the difference between -O0 and DONT_OPTIMIZE? Hmm, I'm not sure there is a difference ... I need to check. At the time of introducing this feature, I vaguely recall that DONT_OPTIMIZE was quite aggressive and so I approximated it by setting -O0 and simply using the strip-flags function (which strips "everything except known good/safe flags" and would thus leave -march and the like alone). Respecting CFLAGS is a Gentoo idiom - up to a point - and can even considered a QA issue. If it does turn out that this approach is superfluous then the snippet in src_configure can simply be dropped and DONT_OPTIMIZE can be added to MENUSELECT_CFLAGS instead. In any case, I don't think it's worth making much of a fuss over; it's the channel and lock debugging features that are particularly useful and Gentoo users are likely setting custom CFLAGS (-g at least) for debugging anyhow. > There is one more thing we can consider - having a way of passing arbitrary > .makeopts stuff - but then again - I believe we ripped that out not too long > ago? (because the method wasn't clean, nor do I see a clean way of dealing > with this) Yes, the user used to be able to set ASTERISK_MODULES. I don't know why Tony dropped it although I remember that the code was rather hairy. It involved a lot of substitution instead of specifying USER_MAKEOPTS which is the way it is supposed to be done. Come to think of it, maybe that was why it was dropped :) It might indeed be useful to re-introduce feature of this kind but it's beyond the scope of this bug. The manner in which I am employing USER_MAKEOPTS here is simply to provide the ebuild itself with a mechanism for defining particular options rather than being entirely confined to upstream's defaults. I'll think it over though.
Hmm, I'd commented on the customisation process way back when: http://bugs.gentoo.org/show_bug.cgi?id=265567#c1 The build process honours /etc/asterisk.makeopts anyway so there's already a method for users to customise as they see fit. Someone just needs to check whether that is overidden by passing USER_MAKEOPTS to make. I don't really want this consideration to derail the introduction of this (useful) feature or the resolution of the long-standing bug concerning (useful) IMAP support though.
if use debug; then for o in DONT_OPTIMIZE DEBUG_THREADS BETTER_BACKTRACES; do menuselect/menuselect --enable $o menuselect.makeopts done fi Tony, you're welcome to unroll the loop (probably recommended, just wanted to save on typing, and it's as much for my crypt-notes as for your information).
We can add REF_DEBUG too.
Stuff REF_DEBUG, it's overkill, and DO NOT ENABLE the above debug on any machine with more than a handful of calls. It just took down a 8-way Xeon machine with more RAM than I can to admit!
+*asterisk-11.6.0-r1 (30 Oct 2013) + + 30 Oct 2013; Tony Vroon <chainsaw@gentoo.org> +asterisk-11.6.0-r1.ebuild: + A useful response to the debug USE-flag, as suggested by Kerin Millar and + implemented by Jaco Kroon. Closes bug #346959.
