By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 1366 - Some insane variables are passed to kde4 applications.
Summary: Some insane variables are passed to kde4 applications.
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdelibs (show other bugs)
Version: R14.0.0 [Trinity]
Hardware: All Linux
: P5 normal
Assignee: Slávek Banko
URL:
Depends on:
Blocks:
 
Reported: 2012-12-14 07:03 CST by Alexander Golubev (Fat-Zer)
Modified: 2012-12-16 18:59 CST (History)
4 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
3.5.13-sru patch (827 bytes, patch)
2012-12-14 07:03 CST, Alexander Golubev (Fat-Zer) 		Details | Diff
r14 patch (793 bytes, patch)
2012-12-14 07:21 CST, Alexander Golubev (Fat-Zer) 		Details | Diff
v3.5.13-sru patch (1.59 KB, patch)
2012-12-16 12:19 CST, Slávek Banko 		Details | Diff
v3.5.13-sru patch (1.70 KB, patch)
2012-12-16 14:18 CST, Alexander Golubev (Fat-Zer) 		Details | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Golubev (Fat-Zer) 2012-12-14 07:03:49 CST 
Created attachment 1054 [details]
3.5.13-sru patch

see the patches.

This is more important for 3.5.13 branch. For R14 those variables just make no scense and they are seems not mandatory at all.
Comment 1 Alexander Golubev (Fat-Zer) 2012-12-14 07:21:25 CST 
Created attachment 1055 [details]
r14 patch

PS: sorry if the bug summary sounds too loud.
Comment 2 Slávek Banko 2012-12-14 07:24:15 CST 
It looks very useful.
Both for R14 and for v3.5.13-sru.
Comment 3 Slávek Banko 2012-12-15 14:01:26 CST 
Note: I looked at the previous value was $HOME/.kde, which seems to be the default value for KDE4. In the patch for v3.5.13-sru therefore I'll change the value back to $HOME/.kde instead of $HOME/.kde4.
Comment 4 Alexander Golubev (Fat-Zer) 2012-12-15 16:14:38 CST 
(In reply to comment #3)
> Note: I looked at the previous value was $HOME/.kde, which seems to be the
> default value for KDE4. In the patch for v3.5.13-sru therefore I'll change the
> value back to $HOME/.kde instead of $HOME/.kde4.
I don't like that cause AFAIK most of disros use ~/.kde4 as default home directory so they'll have to patch this moment. What do you think about using a compile time setting or even an environment variable to set this?
Comment 5 Slávek Banko 2012-12-15 19:16:07 CST 
(Odpověď na komentář #4)
> (In reply to comment #3)
> > Note: I looked at the previous value was $HOME/.kde, which seems to be the
> > default value for KDE4. In the patch for v3.5.13-sru therefore I'll change the
> > value back to $HOME/.kde instead of $HOME/.kde4.
> I don't like that cause AFAIK most of disros use ~/.kde4 as default home
> directory so they'll have to patch this moment. What do you think about using a
> compile time setting or even an environment variable to set this?

I looked in the source files KDE4 and KDE_DEFAULT_HOME default is ".kde". To set is in their CMakeLists.txt used set( ) and does not seem to be somehow conditional. Distribution, which use a different directory so obviously contain a patch for KDE4.

From this perspective, it seems to me as a solution to either use the ".kde" and let each distribution to patch it as needed (as for KDE4) or introduce a variable into CMake.
Comment 6 Alexander Golubev (Fat-Zer) 2012-12-16 06:41:36 CST 
(In reply to comment #5)
> (Odpověď na komentář #4)
> > (In reply to comment #3)
> > > Note: I looked at the previous value was $HOME/.kde, which seems to be the
> > > default value for KDE4. In the patch for v3.5.13-sru therefore I'll change the
> > > value back to $HOME/.kde instead of $HOME/.kde4.
> > I don't like that cause AFAIK most of disros use ~/.kde4 as default home
> > directory so they'll have to patch this moment. What do you think about using a
> > compile time setting or even an environment variable to set this?
> 
> I looked in the source files KDE4 and KDE_DEFAULT_HOME default is ".kde". To
> set is in their CMakeLists.txt used set( ) and does not seem to be somehow
> conditional. Distribution, which use a different directory so obviously contain
> a patch for KDE4.
In cmake all CACHE non-INTERNAL variables represent a user-adjustable values. So in kde4 the variable can be defined with e.g. -DKDE_DEFAULT_HOME=.kde4. 

It would be nice to have the same option for trinity, but it's a long-term perspective. Have we got any place to wright-down such ideas?

> From this perspective, it seems to me as a solution to either use the ".kde"
> and let each distribution to patch it as needed (as for KDE4) or introduce a
> variable into CMake.
If just anybody really need such setting a configuration tweak is always better than make a user patch the source.
Comment 7 Slávek Banko 2012-12-16 12:19:13 CST 
Created attachment 1058 [details]
v3.5.13-sru patch

Because setting KDEHOME no longer needed in the R14, I have prepared a patch for adding a configuration option only for v3.5.13-sru.

It can be that way?
Comment 8 Alexander Golubev (Fat-Zer) 2012-12-16 14:18:51 CST 
Created attachment 1059 [details]
v3.5.13-sru patch

(In reply to comment #7)
> Created attachment 1058 [details]
> v3.5.13-sru patch
> 
> Because setting KDEHOME no longer needed in the R14, I have prepared a patch
> for adding a configuration option only for v3.5.13-sru.
> 
> It can be that way?

No, you should use CACHE variable for this kind of stuff. And IMO it's better to place it with options.

from man cmake:
> In  CMake  there  are two types of variables: normal variables and cache variables. Normal variables are meant for the internal use of the script (just like variables in most programming languages); they are not persisted across CMake runs. Cache  variables  (unless  set  with INTERNAL) are mostly intended for configuration settings where the first CMake run determines a suitable default value, which the user can then override, by editing the cache with tools such as ccmake or cmake-gui. Cache variables are stored in the CMake cache  file,  and  are persisted across CMake runs.
Comment 9 Slávek Banko 2012-12-16 18:59:51 CST 
Fixed in GIT hash 5356a834 (master branch)
and df1b666c (v3.5.13-sru branch).