9 Jun
2012
9 Jun
'12
10:01 p.m.
So I just tried to migrate to trinity (from trunk as of two days ago,
before the latest round of renaming patches). To keep things neat I'm
sticking the whole thing excepting tqtinterface into a tree rooted at
/usr/trinity/ (henceforward '$trinity_root').
I've built up to tdebase, I've noticed the following build problems
(patches follow fixing those for which fixes seem practical). Non-build
problems are mostly not mentioned here because I haven't restarted into
TDE yet (I want to get more built before then).
- If you install tqtinterface as suggested on the wiki, avahi-tqt
fails to build:
make[2]: Entering directory
`/usr/src/kde/trinity/main/dependencies/x86_64-spindle/avahi-tqt'
/usr/trinity/bin/moc moc qt-watch.cpp qt-watch.moc3
TQt meta object compiler
moc: Too many input files specified
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.
I note that even if you *do* install tqtinterface into the
$trinity_root, the pkg-config file ends up in ${prefix}/pkgconfig.
This appears to be intentional, but is quite mystifying given that
all you need to do to avoid it is to set PKG_CONFIG_PATH, which must
be set anyway or the build of tqtinterface will fail (because
qt-mt.pc is not in /usr/lib/pkgconfig but rather in
$trinity_root/lib/pkgconfig.)
Is the expectation nowadays that tqt3 is installed in /usr as well,
or is this a bug?
(I don't have a patch for this because I can't think of a non-insane
fix.)
- in konsole, meta is not recognized (only alt is). I have a pre-existing
patch for this ancient KDE problem.
- covariant return type checking is broken, because it's using the C
compiler rather than the C++ compiler :) but even if that is fixed,
the check still fails, because...
- in the cmake FindTQt module, most of the CXXFLAGS are being missed out,
leading to spurious failures in CheckCXXSourceRuns.
Patches for the latter three problems follow (not as a single git patch
series, though, because I can't figure out how to make one of those
crossing multiple submodules: anyone?)
--
NULL && (void)
10 Jun
10 Jun
12:11 a.m.
New subject: [trinity-devel] A bunch of trunk build patches coming
On 06/09/2012 05:01 PM, Nix wrote:
So I just tried to migrate to trinity (from trunk as
of two days ago,
before the latest round of renaming patches). To keep things neat I'm
sticking the whole thing excepting tqtinterface into a tree rooted at
/usr/trinity/ (henceforward '$trinity_root').
Interesting choice, henceforth perhaps as well.
I've built up to tdebase, I've noticed the following build problems
(patches follow fixing those for which fixes seem practical). Non-build
problems are mostly not mentioned here because I haven't restarted into
TDE yet (I want to get more built before then).
- If you install tqtinterface as suggested on the wiki, avahi-tqt
fails to build:
make[2]: Entering directory
`/usr/src/kde/trinity/main/dependencies/x86_64-spindle/avahi-tqt'
/usr/trinity/bin/moc moc qt-watch.cpp qt-watch.moc3
TQt meta object compiler
moc: Too many input files specified
Hmm.. There was a push to put tqtinterface in /usr (I don't have the reason), so
that is what I've done, basically building with:
[ "$QTDIR" = "" ] && . /etc/profile.d/tqt3.sh
_prefix=/usr
_tdedir=/opt/trinity
mkdir -p build
cd build
cmake "../tqtinterface" \
-DCMAKE_INSTALL_PREFIX=${_prefix} \
-DQT_PREFIX_DIR=${QTDIR} \
-DQT_INCLUDE_DIR=${QTDIR}/include \
-DMOC_EXECUTABLE=${QTDIR}/bin/moc \
-DQT_VERSION=3
make
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 note that even if you *do* install tqtinterface into the
$trinity_root, the pkg-config file ends up in ${prefix}/pkgconfig.
This appears to be intentional, but is quite mystifying given that
all you need to do to avoid it is to set PKG_CONFIG_PATH, which must
be set anyway or the build of tqtinterface will fail (because
qt-mt.pc is not in /usr/lib/pkgconfig but rather in
$trinity_root/lib/pkgconfig.)
Is the expectation nowadays that tqt3 is installed in /usr as well,
or is this a bug?
(I don't have a patch for this because I can't think of a non-insane
fix.)
:)
- 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.
- covariant return type checking is broken, because
it's using the C
compiler rather than the C++ compiler :) but even if that is fixed,
the check still fails, because...
- 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!
Patches for the latter three problems follow (not as a
single git patch
series, though, because I can't figure out how to make one of those
crossing multiple submodules: anyone?)
Tim will have to weigh in on the git issues - it is still largely Greek to me.
I'll work to digest the patches. Darrell, you want to weigh in here?
--
David C. Rankin, J.D.,P.E.
9:28 a.m.
New subject: [trinity-devel] A bunch of trunk build patches coming
On 10 Jun 2012, David C. Rankin told this:
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.
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)
On 06/09/2012 05:01 PM, Nix wrote:
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...)
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. - 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. - 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!
4659
days inactive
4660
days old
2 comments
2 participants
participants (2)
-
David C. Rankin -
Nix