It is possible and I will probably do so.  Trouble is I am not sure exactly how to do that with Automake, so it may take some time to implement.

Good to hear. Thanks!

I take it Slackware builds kdepim with the majority of the kresources folder disabled?  Most of the resources in there are for enterprise use as well; just curious if  the problem is merely the external dependency or if it is directly related to the added functionality.

I'm not following what you mean by that. There is nothing in the configure settings like that. OTOH, I haven't looked at kdepim configure --help to notice whether any of those related settings need to be explicitly enabled and hence, in Slackware are disabled by default.

Would you provide more details what you are seeking?

Generally speaking, Slackware is not built to accompany all types of users. There have been times through the years when I had to add configure options to a package and rebuild. Further, Slackware tends to stay primarily focused on geeks, oops, technical users, and servers. At times with his development perspective, I think Patrick Volkerding was pulled into the 21st century kicking and screaming. The guy knows his stuff but his focus is very much old school. His philosohphy is that he is providing a base operating system that end-users build upon and he does not provide a full-featured system or even try. That actually is what attracts many people to Slackware.

With that said, regarding the lib*dav* stuff, I'm speaking only from my own perspective. I just have no use for social networking, semantic desktops, online apps, etc. In that respect, I tend to be old school too.

The new feature should be present in SVN revision 1174561 or higher.  It will detect when libcarddav or libcaldav are not present and automatically deactivate the affected resource(s).

...

I agree 100% there.  My earlier comment was based on this: The caldav/carddav libraries add the same type of functionality as was already present in kdepim resources such as Kolab and GroupDAV, which are always built (there is no way to shut them off; this has been so since their creation many, many KDE3 releases ago)  The only difference is that those resources don't rely on an external dependency.  So, I gather that the reason you want to deactivate carddav/caldav support is due to the external dependency required; not because the added functionality is unwanted.

This also brings up another question: Do you want the ability to individually deactivate each resource present in the kresources folder? Since I figured out how to do this type of operation it won't be as difficult.

Parts of what you are explaining just results in glassy eyes. :) Let me see whether I can answer your quesations.

Traditionally, KDE always has been built in Slackware using stock sources. If you say much of the functionality was already provided within KDE, then in a stock Slackware that functionality would be present too. Patrick is not known for patching upstream sources to add or delete features. That attitude probably has much to do with why Slackware systems seem faster than other systems.

Of course, the definition of "stock" changes in Trinity. If I understand correctly, you have taken some built-in functionality and moved those features outside of KDE, which allows more than just kdepim to take advantage. In that respect then, building libical, libcaldav, and libcarddav as required dependencies makes sense because in the end KDE has the same functionality.

If I understand correctly, if a user's system does not have any DAV tools, then those features within kdepim become dead-end stubs.

As far as building packages, I suppose the end result is the same. From a pragmatic perspective, whether the functionality is built-in or external is immaterial. What is, is.

I can't speak for other Slackware users. I have no idea whether many or most want or need DAV hooks. I have no idea. I do know that traditionally, if a Slackware user thinks or perceives that software is bloated, then you might as well release the hounds. They never will use Trinity if the general belief among Slackware users is Trinity is bloated. Worse, they will spread their belief loudly. I have been a part of that community for several years. As I mentioned previously, I have fought that anal outlook just as long. Yet I also know I am unlikely to win the battle. The majority of Slackware users will not tolerate anything resembling bloat.

These are people who don't use GUI package managers. Your Kubuntu and Debian followers likely have no idea of what transpires and gets installed when they run Synaptic. Nor do they care. Slackers know. They do care. Period. If they consider additional packages to be bloat because those packages previously were not needed in KDE 3.5.x, then you've lost that potential target audience. Slackers can be a mean brutal bunch. Many times I have considered leaving to find a different distro, but nothing provides me the flexibility that Slackware provides.

Now for some philosophy. :)

I'm still mad at the KDE developers. They have no idea about focusing on users. They focus only on themselves. Their definition of users are fellow geeks. Bling, bling, bling. Screw the basic everyday user.

I think Trinity can fill that void. The everyday user doesn't care about bling, enterprise features, or online apps. The everyday user never uses any of that and likely never will. Most everyday users just want the basics.

I have been in technical and engineering fields all of my adult life (30+ years). Simple approach: function before form. The KDE developers have forgotten that simple engineering adage.

Another thing the KDE developers have forsaken are users of older hardware. Once upon a time there was a belief that Linux based systems kept old hardware out of the landfills. Not so with KDE4, that's for sure.

I have five machines here networked, but I look at usage as a single user and not an enterprise user or geek. I don't use online apps. I reject the idea of placing my data somewhere out there in the nether land called the cloud. I don't use korganizer. I use kalarm for same basic reminders. I don't use kaddressbook. I'm content with the simple list kmail creates. I don't use kopete or any other instant messenger. Shoot, I refuse to enable the answering machine devices on my phones. :)

Simply put, I like my life simple. Most people do. Computers are supposed to help us, not hinder us. Bling and bloat introduces the latter, not the former.

Thus, I don't like having various features built into software that I am unlikely to use. I accept that other people find them useful. Yet every little bit added, even if the result is just a hook or stub, means longer startup times, additional RAM usage, etc. Many developers these days never notice or care because they all use modern hardware. My main system is a dual core box, but I have some old machines here. They run KDE 3.5.10. They never will be able to run KDE4.

My concern is that Trinity might grow to the point that those old machines no longer can run KDE 3.5.x comfortably. I want to see Trinity become a viable desktop alternative for old hardware and users who do not buy into the KDE developer's rah-rah.

I think Trinity can fill that void of people using old hardware. Yet every little hook and stub consumes resources. Almost every piece of software nowadays utterly shuns the user of old hardware. My point is why should people still run Windows 95 or 98 because they want to keep using old hardware? Running Windows for Workgroups 3.11 on my old 486 with 16 MB of RAM is in many ways snappier than KDE 3.5.10 on my Pentium I and II machines. That is sad.

Xfce is nowhere near as configurable as KDE 3.5.x. LXDE is an immature and unstable product (but getting better). Most everyday users want a desktop environment, not a window manager. They want point-and-click configuration, not to open terminal windows and text editors. I don't think either of those desktops will ever provide the configurability of KDE 3.5.x. The primary target for those desktops are the technically inclined, not the everyday user.

My reason for the option to deactivate carddav/caldav support is the folks running old hardware. I'm only seeking the option to disable, not a requirement. Every little bit of overhead makes a difference on old hardware. Those old machines don't have gigabytes of RAM, they have 256 MB. Distro maintainers would likely keep those hooks enabled as the default. Folks like me who want to build for older hardware can have the option to disable that overhead.

The overhead of supporting DAV might be immeasurable in both RAM and performance hit. Fair enough and likely true for modern hardware. Is the same true for old hardware? I don't know and won't speculate.

With that said, I think all developers should have one old box to test their software. Old hardware provides a new perspective on efficiency and speed.

Should package builders have the option to disable many of these resources? Yes, they should have the option. Possibly Trinity can be delivered in two flavors. One is with all hooks enabled. The other with most disabled. Users of older hardware and those who don't need bling can download the latter set of packages. Just a thought.

I hope I haven't overstayed my welcome!

Great idea!  Shouldn't be too difficult either; two separate repositories built from the same source, but with different configure options, should do the trick.

...

I hope I haven't overstayed my welcome!

Not at all!  The Trinity project should be learning from KDE4's mistakes, not repeating them. ;-)

In fact, when I go into kdepim to fix your build failure, I will add flags to disable each resource independently.  Then I'll leave it up to you to disable any resources that Slackware users won't be interested in.

Mostly I'm a disgruntled user. I don't like GTK, I don't like KDE4, I don't like window managers, preferring robust desktops. I feel betrayed by the KDE developers. An argument can be made those people owe me nothing, but a counter argument is valid too. To be part of a community requires reciprocating relationships.

A significant point about whether to enable or disable various features. Documentation. I like the idea very much. Especially if I can create packages pared to work better on older hardware. However, we need documentation. Well, I need documentation --- I need some kind of basic punch list of those options for each package before I can write anything.

We can place those build options on the wiki. I likely would add lots of commentation in my build scripts too.

Yes, I can run configure --help before every build, but I'm not a developer with years of experience in that area. I do not know what to look for or necessarily recognize what I read. I can write, but I need guidance as to what needles I am looking for and in what haystacks.

Regarding building kdepim.

Successfully built.

I have no explanation. I installed libcaldav but not libcardav because we don't know know yet why that package does not compile. With libcaldav installed the kdepim package compiled for the first time.

Yet as my previous message stated, without libcaldav the build fails.

Of course, to be considered bug-free with respect to compiling, we need to be able to compile with or without the lib*dav packages.

If you support enabling/disabling various options, then compiling needs to test those variations.

I still have made no headway with the other three packages: kdebindings, koffice, and kdemultimedia. Of course, all of them require significant time to compile. Each FTB is discouraging because of the time required.

I can look into putting my HTPC into part-time use when not recording or viewing (another dual core machine). If only we can get all the basic packages to compile!