Message: previous - next
Month: June 2012

Re: [trinity-devel] A bunch of trunk build patches coming

From: Nix <nix@...>
Date: Sun, 10 Jun 2012 10:28:05 +0100
On 10 Jun 2012, David C. Rankin told this:

> On 06/09/2012 05:01 PM, Nix wrote:
>>    This is in part because moc-tqt cannot be found. If we follow the
>>    wiki's instructions and install tqtinterface in /usr, it ends up in a
>>    different place from TQt and the configure-time search for tmoc
>>    fails. Moving tqtinterface into the $trinity_root fixes that, but
>>    then the hardwired -I/usr/include/tqt is wrong and the build fails
>>    again. The only fix I've found is to install tqtinterface into the
>>    $trinity_root, and then symlink /usr/include/tqt to that location.
>>    This is, not to put too fine a point on it, insane.
>   That I understand. No point to fine to be drawn. I would like to see the
> packages flexible enough to be put anywhere. Either in /opt, /usr, or where
> ever. Personally, I would like to see everything in /opt/tde or /usr/tde.

I'm not objecting to tqtinterface in /usr (much): I'm objecting to
having to put it in one place and symlink bits of it into another :)

More generally. Trinity should not *care* where it's installed. Nothing
else on my system does. Even Qt eventually learned the difference
between configure-time and install-time prefix, and allowed both to be
set to anything. cmake and autoconf both understand this natively:
hardwired paths are just ugly. (And easily fixable with configure-time-
substituted pkg-config variables...)

>>  - in konsole, meta is not recognized (only alt is). I have a pre-existing
>>    patch for this ancient KDE problem.
> I haven't noticed this yet specifically. Mostly because I test in virtualbox and
> it's hard for me to tell which meta strokes are picked up by the virtual machine
> and which are picked up by the native desktop.

What, you don't use Trinity as your actual desktop? :) this bug is
*ancient*: I first rolled it against KDE 2.something. If your desktop is
KDE anything you'll be afflicted.

>>  - in the cmake FindTQt module, most of the CXXFLAGS are being missed out,
>>    leading to spurious failures in CheckCXXSourceRuns.
> The odds are good that there are many subtle issues yet to be found. The more
> help like this you can give, the quicker they will be found and fixed. Thanks!

I have no choice now, KDE 3.5.10's kded has frozen solid and diagnosing
it seems pointless when there is a maintained alternative like Trinity.

Assuming I can build it... :)

NULL && (void)