Guys,
One small build for a man, and one giant leap for Arch packages building from git :)
After finally getting the cmake and admin directories populated, tqtinterface guilt without issue from the latest git! The first proud package:
trinity-tqtinterface-3513-4-x86_64.pkg.tar.xz
If the rest of the tree goes as well, this should be a timely breeze (loud knocking on wood). I have created tarballs from the git tree and they seem to be working fine building in an archroot.
Do we have a tally as to home much of tde should be building at this time from the git tree? I saw Samelaine's announcement saying the packages were all done - does this mean I could start now and conceivably build a majority of tde? First looks -- look good!
Do we have a tally as to home much of tde should be building at this time from the git tree? I saw Samelaine's announcement saying the packages were all done - does this mean I could start now and conceivably build a majority of tde? First looks -- look good!
For the past two days I have built the full main suite and a dozen additional packages from each day's latest GIT. I built against Qt3 and not TQt3. Regarding TQt3, Tim is working on some bugs some of us are experiencing when building against TQt3.
Note: tdebindings will not build against Qt3 and hasn't built against Qt3 for a long time. Only TQt3.
Darrell
On 02/18/2012 11:32 AM, Darrell Anderson wrote:
For the past two days I have built the full main suite and a dozen additional packages from each day's latest GIT. I built against Qt3 and not TQt3. Regarding TQt3, Tim is working on some bugs some of us are experiencing when building against TQt3.
Note: tdebindings will not build against Qt3 and hasn't built against Qt3 for a long time. Only TQt3.
Darrell
So you suggest TQt3 only as a base for building TDE? What difference does it make for the desktop? All styles, themes, functionality still the same when based on TQt3?
For the past two days I have built the full main suite
and a dozen additional packages from each day's latest GIT. I built against Qt3 and not TQt3. Regarding TQt3, Tim is working on some bugs some of us are experiencing when building against TQt3.
Note: tdebindings will not build against Qt3 and hasn't
built against Qt3 for a long time. Only TQt3.
So you suggest TQt3 only as a base for building TDE? What difference does it make for the desktop? All styles, themes, functionality still the same when based on TQt3?
I wasn't recommending anything, only sharing my recent experience. :)
Currently building against TQt3 is broken. Tim will post when he has that fixed. Until then use Qt3. :)
Tim will have to explain the difference between TQt3 and Qt3. I don't know whether the latter will be dropped eventually. However, as tdebindings will not build against Qt3 and Tim has stated he will not fix the problem, that means tdebindings will build only against TQt3 (when fixed). That more or less makes Qt3 obsolete for anybody wanting to build tdebindings.
Clear as mud, right? :)
Darrell
For the past two days I have built the full main suite
and a dozen additional packages from each day's latest GIT. I built against Qt3 and not TQt3. Regarding TQt3, Tim is working on some bugs some of us are experiencing when building against TQt3.
Note: tdebindings will not build against Qt3 and hasn't
built against Qt3 for a long time. Only TQt3.
So you suggest TQt3 only as a base for building TDE? What difference does it make for the desktop? All styles, themes, functionality still the same when based on TQt3?
I wasn't recommending anything, only sharing my recent experience. :)
Currently building against TQt3 is broken. Tim will post when he has that fixed. Until then use Qt3. :)
Tim will have to explain the difference between TQt3 and Qt3. I don't know whether the latter will be dropped eventually. However, as tdebindings will not build against Qt3 and Tim has stated he will not fix the problem, that means tdebindings will build only against TQt3 (when fixed). That more or less makes Qt3 obsolete for anybody wanting to build tdebindings.
Clear as mud, right? :)
Darrell
TQt3 allows the TDE developers to use Qt4 libraries within TDE applications, e.g. Webkit. Qt3 does not allow this due to C++ namespace conflicts (technically it is a problem with both the compiler and linker caused by two different definitions of common classes such as QObject, but the previous description gets the point across in a succinct manner).
I strongly recommend using tqt3 if posssible, but am keeping qt3 compatibility via tqtinterface for everything except the language bindings modules (tdebindings, python-tqt, etc.).
Does this help?
Tim
TQt3 allows the TDE developers to use Qt4 libraries within TDE applications, e.g. Webkit. Qt3 does not allow this due to C++ namespace conflicts (technically it is a problem with both the compiler and linker caused by two different definitions of common classes such as QObject, but the previous description gets the point across in a succinct manner).
I strongly recommend using tqt3 if posssible, but am keeping qt3 compatibility via tqtinterface for everything except the language bindings modules (tdebindings, python-tqt, etc.).
Does this help?
Clear as mud. :)
You wrote "...am keeping qt3 compatibility via tqtinterface..." When building with TQt3, do we still have to build tqtinterface too? Or is tqtinterface required only when building with Qt3? I could discover the answer the hard way next time I build....
Darrell
TQt3 allows the TDE developers to use Qt4 libraries within TDE applications, e.g. Webkit. Qt3 does not allow this due to C++ namespace conflicts (technically it is a problem with both the compiler and linker caused by two different definitions of common classes such as QObject, but the previous description gets the point across in a succinct manner).
I strongly recommend using tqt3 if posssible, but am keeping qt3 compatibility via tqtinterface for everything except the language bindings modules (tdebindings, python-tqt, etc.).
Does this help?
Clear as mud. :)
You wrote "...am keeping qt3 compatibility via tqtinterface..." When building with TQt3, do we still have to build tqtinterface too? Or is tqtinterface required only when building with Qt3? I could discover the answer the hard way next time I build....
Darrell
tqtinterface is required in all cases. If you have any questions feel free to ask!
Tim
tqtinterface is required in all cases.
Ok. :)
If you have any questions feel free to ask!
The problem is between my ears. A wiki technical article with pictures would be helpful. Yeah, I know, like you don't have enough to do already. :)
Darrell
On 02/18/2012 03:14 PM, Darrell Anderson wrote:
I wasn't recommending anything, only sharing my recent experience. :)
Currently building against TQt3 is broken. Tim will post when he has that fixed. Until then use Qt3. :)
Tim will have to explain the difference between TQt3 and Qt3. I don't know whether the latter will be dropped eventually. However, as tdebindings will not build against Qt3 and Tim has stated he will not fix the problem, that means tdebindings will build only against TQt3 (when fixed). That more or less makes Qt3 obsolete for anybody wanting to build tdebindings.
Clear as mud, right? :)
Darrell
Last time Tim helped me with the Qt3/TQt3 question, I understood they were identical except that TQt3 uses TQ* object names internally allowing it to be compiled into programs along with Qt4. I have no understanding beyond that. Yes -- clear as mud :)
Le 18/02/2012 22:46, David C. Rankin a écrit :
Last time Tim helped me with the Qt3/TQt3 question, I understood they were identical except that TQt3 uses TQ* object names internally allowing it to be compiled into programs along with Qt4. I have no understanding beyond that. Yes -- clear as mud :)
As a side-effect which I'm interested in, TQT3 should be able to co-exist under "/usr" with any distribution-provided QT3 and/or QT4 version. So, legacy QT3/KDE3 programs shipped with the distro will use the legacy QT3, KDE4 programs will use QT4, and TDE will use TQT3, and everyone should be happy :)
On my current TDE 3.5.13 build, it looks like the QT 3.3.8.D, that I've packaged as an update to the distro-provided QT 3.3.8.B, makes some legacy QT3 programs crash, but I do not know why. As I understood, QT 3.4.0 for future TDE R14 will officially break compatibility with QT 3.3.8, so having both QT3.3.8.B and TQT 3.4.0 at the same time is mandatory for me.
Francois
As a side-effect which I'm interested in, TQT3 should be able to co-exist under "/usr" with any distribution-provided QT3 and/or QT4 version. So, legacy QT3/KDE3 programs shipped with the distro will use the legacy QT3, KDE4 programs will use QT4, and TDE will use TQT3, and everyone should be happy :)
I too am interested in complete installation compatibility. :) One challenge is the bin files in Qt3 are the same as those in Qt4. That is not a problem per se, but is confusing, especially when creating sym links in /usr/bin.
On my current TDE 3.5.13 build, it looks like the QT 3.3.8.D, that I've packaged as an update to the distro-provided QT 3.3.8.B, makes some legacy QT3 programs crash, but I do not know why. As I understood, QT 3.4.0 for future TDE R14 will officially break compatibility with QT 3.3.8, so having both QT3.3.8.B and TQT 3.4.0 at the same time is mandatory for me.
As I recall, whatever was done from 3.3.8.c to 3.3.8.d was strictly Trinity related and broke backwards compatibility. Our own Qt3 change log is, um, vague as to the specific changes and the reasons for breaking backwards compatibility. Regardless, KDE3 apps cannot use Qt3 3.3.8.d. Non KDE3 Qt3 apps might still work, but would need to be recompiled against 3.3.8.d rather than the original 3.3.8.b.
In our proposed FAQ we discuss backwards compatibility but we really do not address the technical aspects. :(
Darrell
On 02/18/2012 04:13 PM, Darrell Anderson wrote:
On my current TDE 3.5.13 build, it looks like the QT
3.3.8.D, that I've packaged as an update to the distro-provided QT 3.3.8.B, makes some legacy QT3 programs crash, but I do not know why. As I understood, QT 3.4.0 for future TDE R14 will officially break compatibility with QT 3.3.8, so having both QT3.3.8.B and TQT 3.4.0 at the same time is mandatory for me.
As I recall, whatever was done from 3.3.8.c to 3.3.8.d was strictly Trinity related and broke backwards compatibility. Our own Qt3 change log is, um, vague as to the specific changes and the reasons for breaking backwards compatibility. Regardless, KDE3 apps cannot use Qt3 3.3.8.d. Non KDE3 Qt3 apps might still work, but would need to be recompiled against 3.3.8.d rather than the original 3.3.8.b.
In our proposed FAQ we discuss backwards compatibility but we really do not address the technical aspects. :(
Darrell
I hate breaks in backwards compatibility, but I understand enough to know that sometimes it is unavoidable. However, when a break is required, we must all be diligent in identifying those programs that are broken by it and restore/rebuild them to prevent losing functionality.
Progress is fickle. How much progress is there if for instance a gcc change breaks a decade worth of software compatibility requiring millions of applications to be updated just to build again? The gcc 4.5 constructor change requiring all code with TQString::TQString() to be changed to TQString(). I'm sure it made sense for the future, but what a PITA...
-
Darrell Anderson -
David C. Rankin -
François ANDRIOT -
Timothy Pearson