[mythtv] Mixed debug/release build

[Michael Haas]

Daniel Kristjansson wrote:
> <snip>
> I'll take this as a vote in favor of #3589, with the recognition
> that it may require changes in how the packages are built.
>   

Let's hope it won't require changes - the current Ubuntu setup (with
separate debug packages created automagically etc) is already simple and
elegant enough to be kept around for a while, IMHO. Maybe there could be
two release-dbg targets: one with my changes and one with #3589, eg
partially optimized and symbols put in a different file.

Axel Thimm has separate .rpm files for symbols, too - I wonder how he
makes them and if he'd benefit from #3589. Still, #3589 seems to make a
lot of sense for people building at home or for distributions which
currently don't provide dbg symbols.

> Tune i486 is probably based on wanting the 10% speedup of cmov that
> i486 has over i386, but still wanting to work on most Intel/AMD CPUs.
>   
Google tells me that cmov was introduced with the pentium pro.
Unfortunately, some VIA CPUs don't support CMOV.


> MMX and SSE can give a significant boost as well, but I'm not sure
> how these options will be handled by configure, tune and enable-proc-opt
> are not meant to be used together.
>
>   
We'll stop using --enable-proc-opt soon, I think. Also, we're already
using --enable-mmx (forgot to mention that).

>> This depends, while an optimized build can be debugged, it results in
>> non useful backtraces more often than non-optimized builds. This means
>> we need the users help to diagnose the problem. Tickets in our trac
>> are generated by users so we assume we will be able to get that help.
>> With automatically generated reports we don't have that help so they
>> should really go in a separate trac, where we just close tickets
>> without the overhead of describing why the backtrace is not useful.
>>     
Thanks for clarifying that. We do have our own bug tracker at
<http://launchpad.net>, but I'm not sure if the MythTV developers would
like to use that. The first tickets we submitted were automatically sent
to our bug tracker, BTW, and forwarded manually to trac. If you're just
concerned about closing tickets without giving a lengthy reason - no
worries, we wouldn't be offended. :)

>> Can you add the patch to the #3589 ticket and
>> explain what it does (you can copy your initial e-mail)?
>>
>>     
Yes.


Regards,

Michael