Guys & Gals,
(with restored political correctness), where do the additional dependencies apps fit in the build order and which will not build if the system is based on Qt3. Specifically, the following are in the tree, but appear to not have previous build scripts on Arch:
dependencies-avahi-tqt dependencies-libart-lgpl dependencies-libcaldav dependencies-libcarddav dependencies-python-tqt dependencies-sip4-tqt dependencies-tqca-tls dependencies-tqscintilla
The build order lists:
tqtinterface arts dbus-tqt dbus-1-tqt tdelibs <snip>
I presume the above dependencies would be built prior to tdelibs. Without trying each individually, do we know which ones won't build unless TQt3 is used instead of Qt3? Also, is there any order in which they must be built? (don't think so, but I thought I would check...)
python-tqt, sip4-tqt and tqscintilla all seem to be related to python/C++ bindings - is there any functionality they provide for TDE beyond development that a normal desktop user would care about?
I have no problem backing up and starting over with TQT3, but my understanding is it is still waiting on a few fixes from Tim. Where will be get the announcement that TQt3 is considered ready to go? git changelog? list?
Sorry for the list of questions, but in trying to get as much done as possible, I would like to avoid wasting effort if possible and the HowToBuild wiki left these issues open.
Ok my limited experience building under qt3
tqtinterface arts dbus-tqt dbus-1-tqt tdelibs tdebase
dependencies-avahi-tqt (would not build) dependencies-libart-lgpl (built) dependencies-tqca-tls (built)
The others i had no need for and therefore didn't try.
Jay
On Sun, Feb 19, 2012 at 9:25 PM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
Guys & Gals,
(with restored political correctness), where do the additional dependencies apps fit in the build order and which will not build if the system is based on Qt3. Specifically, the following are in the tree, but appear to not have previous build scripts on Arch:
dependencies-avahi-tqt dependencies-libart-lgpl dependencies-libcaldav dependencies-libcarddav dependencies-python-tqt dependencies-sip4-tqt dependencies-tqca-tls dependencies-tqscintilla
The build order lists:
tqtinterface arts dbus-tqt dbus-1-tqt tdelibs
<snip>
I presume the above dependencies would be built prior to tdelibs. Without trying each individually, do we know which ones won't build unless TQt3 is used instead of Qt3? Also, is there any order in which they must be built? (don't think so, but I thought I would check...)
python-tqt, sip4-tqt and tqscintilla all seem to be related to python/C++ bindings - is there any functionality they provide for TDE beyond development that a normal desktop user would care about?
I have no problem backing up and starting over with TQT3, but my understanding is it is still waiting on a few fixes from Tim. Where will be get the announcement that TQt3 is considered ready to go? git changelog? list?
Sorry for the list of questions, but in trying to get as much done as possible, I would like to avoid wasting effort if possible and the HowToBuild wiki left these issues open.
-- David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
dependencies-avahi-tqt dependencies-libart-lgpl dependencies-libcaldav dependencies-libcarddav dependencies-python-tqt dependencies-sip4-tqt dependencies-tqca-tls dependencies-tqscintilla
The build order lists:
tqtinterface arts dbus-tqt dbus-1-tqt tdelibs
<snip>
I presume the above dependencies would be built prior to tdelibs. Without trying each individually, do we know which ones won't build unless TQt3 is used instead of Qt3? Also, is there any order in which they must be built? (don't think so, but I thought I would check...)
python-tqt, sip4-tqt and tqscintilla all seem to be related to python/C++ bindings - is there any functionality they provide for TDE beyond development that a normal desktop user would care about?
I am building against TQt3 right now. Mostly going well, but I'll need to report a handful of build issues.
Regarding dependencies and order:
avahi-tqt and libart-lgpl must be built before tdelibs. The former is optional, the latter is not.
libcaldav and libcarddav must be built before tdepim. Both are optional. The tdepim build options include -DWITH_CALDAV and -DWITH_CARDDAV. When set to ON then both of the dependency packages must be built and installed.
I never have read anything about the build order for tqca-tls, but I always build that package after tqtinterface and before building arts. By the way, the original qca package never was converted to tqca (bug report 817).
The remaining three dependency packages are tdebindings related as far as I know. I have yet to build any of them although that is on my to-do list. Before GIT, tdebindings build without problems with or without any of those dependencies. If those packages are not installed then tdebindings should build but without that component support. When we finally get the bugs out of building tdebindings the same will apply. Some folks want to drop tdebindings altogether, others don't. That package doesn't mean much to most users --- unless and until they use a third party package that expects those bindings. A while ago we discussed how many of the bindings remained valid and we don't know.
Not mentioned are the various libraries packages. I believe three of them are tdebindings related: libtqt-perl, pytdeextensions, and python-trinity. I haven't tried to build those. The other libraries are graphics related, such as support for gwenview, digikam, etc. I believe all libraries packages are optional.
The bottom line is we all (including me!) need to start building all of these packages, whether or not we find them useful. That is the only way we will discover build issues and bugs. :)
Darrell
On 02/19/2012 03:43 PM, Darrell Anderson wrote:
I am building against TQt3 right now. Mostly going well, but I'll need to report a handful of build issues.
Regarding dependencies and order:
avahi-tqt and libart-lgpl must be built before tdelibs. The former is optional, the latter is not.
Got it :)
libcaldav and libcarddav must be built before tdepim. Both are optional. The tdepim build options include -DWITH_CALDAV and -DWITH_CARDDAV. When set to ON then both of the dependency packages must be built and installed.
There should NOT be a desktop built today that is NOT fully caldav/carddav/webdav aware. The basic critical functionality they provide to interface with groupware backends (eGroupWare - my preference) is required in 2012.
As an illustration, iOS is fully 'dav' aware while Android is not. For businesses with groupware backends, there is no choice, iOS wins hands down. Android does NOT provide this capability and the 3rd party pay-for Android apps the supposedly support it are hit or miss making Android useless compared to iOS in this situation. The 'davs' provides seamless integration to calendar and contacts with bi-directional update capabilities.
I would pretty much consider them a MUST for TDE if TDE is going to be a modern competitive desktop from a base capabilities standpoint.
I never have read anything about the build order for tqca-tls, but I always build that package after tqtinterface and before building arts. By the way, the original qca package never was converted to tqca (bug report 817).
The remaining three dependency packages are tdebindings related as far as I know. I have yet to build any of them although that is on my to-do list. Before GIT, tdebindings build without problems with or without any of those dependencies. If those packages are not installed then tdebindings should build but without that component support. When we finally get the bugs out of building tdebindings the same will apply. Some folks want to drop tdebindings altogether, others don't. That package doesn't mean much to most users --- unless and until they use a third party package that expects those bindings. A while ago we discussed how many of the bindings remained valid and we don't know.
Not mentioned are the various libraries packages. I believe three of them are tdebindings related: libtqt-perl, pytdeextensions, and python-trinity. I haven't tried to build those. The other libraries are graphics related, such as support for gwenview, digikam, etc. I believe all libraries packages are optional.
The bottom line is we all (including me!) need to start building all of these packages, whether or not we find them useful. That is the only way we will discover build issues and bugs. :)
Darrell
+1, I want to see TDE the #1 desktop and it won't get there if it only provides 3/4 of the packages and capabilities that 3.5.10 did :)
There should NOT be a desktop built today that is NOT fully caldav/carddav/webdav aware. The basic critical functionality they provide to interface with groupware backends (eGroupWare - my preference) is required in 2012.
Required? Maybe. Maybe not. :) I don't use any of those options. I'm not a gadget freak and don't carry my life around in a gadget. I also am a privacy advocate and will never post private information on any online service or cloud server. Yeah, I'm weird. ;) I also see many home users not needing those options. Nonetheless, I build my packages with those features because others use my packages.
If you look at the commit log for the 16th, you'll see that Tim moved those two packages to the dependencies tree. I presume they remain optional dependencies like avahi-tqt, but no longer are those packages cleverly hidden deep in Tim's web site. :)
Darrell
On 02/19/2012 05:44 PM, Darrell Anderson wrote:
Required? Maybe. Maybe not. :) I don't use any of those options. I'm not a gadget freak and don't carry my life around in a gadget. I also am a privacy advocate and will never post private information on any online service or cloud server. Yeah, I'm weird. ;) I also see many home users not needing those options. Nonetheless, I build my packages with those features because others use my packages.
I'm not really in love with gadgets myself, but for basic "when it gets entered on my calendar at the office it shows up on my desktop/device" regardless where I am -- or when I'm asked "does this day work with you?" -- it is pretty much what is expected today. With caldav built into TDE, then kdepim or other apps would have this native capability. Granted, there are many desktop tools that can do this, but to continue with kde <= 3 philosophy of providing top-of-the-line no-frills capability, the 'davs' get my vote for being a part of that 'good core functionality'
Don't get me wrong. I'm not arguing with you about them, I'm just providing background as to why I have found the 'davs' (which are pretty obscure pieces of code) indispensable. Not that they are immediately usable by every desktop user, but because they provide a means to integrating the desktop with remote calendar and contact servers and provide a 'toolset' for developing pretty neat features in the years to come.
I don't know what Tim's motivation was for moving them into dependencies, but I agree with it :)
If you look at the commit log for the 16th, you'll see that Tim moved those two packages to the dependencies tree. I presume they remain optional dependencies like avahi-tqt, but no longer are those packages cleverly hidden deep in Tim's web site. :)
Darrell
I have caldav built, I'm still working on carddav.
-
Darrell Anderson -
David C. Rankin -
Jay