20 Aug
2012
20 Aug
'12
6:55 a.m.
Tim, Darrell, All,
In the process of attempting to get the khelpcenter documents all collected in
one spot in 3513-sru, I have found a simple setting that will allow both R14 and
3513-sru to standardize their document locations. The primary issue is that the
base document path is hardcoded in tdelibs/kdecore/kstandarddirs.cpp on lines
1041-1042:
1041 if (!strcmp(type, "html"))
1042 return "share/doc/kde/HTML/";
All autotools build packages, on the other hand, set the equivalent path to:
return "share/doc/HTML/";
During April (10 & 11), Darrell fixed the R14 document locations. At that time
there was no focus on 3513-sru as a branch. Instead of changing the hardcoded
location in tdelibs to remove ../kde/.. to match all autotools package locations
and changing the CMake files as originally envisioned, hundreds of individual
patches were submitted to change all autotools acinclude.m4 files to move
helpcenter docs from:
kde_htmldir='\${datadir}/doc/HTML'
to
kde_htmldir='\${datadir}/doc/tde/HTML'
That works fine for R14, but interjects incompatibility between R14 and 3513
essentially requiring 2-sets of hundreds of patches just to change the
kde_htmldir to '\${datadir}/doc/tde/HTML' (in the case of R14) and to
'\${datadir}/doc/kde/HTML' (for 3513).
Why not fix this once and for all, fix tdelibs, and just set:
kde_htmldir='\${datadir}/doc/HTML'
for all??
That way, instead of patching hundreds of autotools packages, the original
location in tdelibs is standardized where it should be in 'kstandarddirs.cpp',
the CMake files are corrected to match the original kde_htmldir locations in
their sources, and all future CMake migration can go forward without every set
of files having to set kde_htmldir and reset it for 3513 in another set of
patches... (this stuff should be standard anyway -- there is absolutely no need
to have 'kde' or 'tde' in the middle of kde_htmldir)
This would eliminate hundreds of patches required to change to 'tde' for R14
and to 'kde' for 3513 and move all sources back closer to their pristine state.
This couldn't have been envisioned in April, but if we are serious about
providing a 3513-sru branch and R14, then I think this is the right way to do it.
See: http://www.trinitydesktop.org/patches/ The set of commits at issue are
between the following:
398ef116 2012-04-10
4e430ec6 2012-04-11
Thoughts?
--
David C. Rankin, J.D.,P.E.
20 Aug
20 Aug
10:26 a.m.
New subject: [trinity-devel] Why not standardize kde_htmldir='\${datadir}/doc/HTML' ??
Why not fix this once and for all, fix tdelibs, and
just set:
kde_htmldir='\${datadir}/doc/HTML'
for all??
That way, instead of patching hundreds of autotools
packages, the original location in tdelibs is standardized where it should be in
'kstandarddirs.cpp', the CMake files are corrected to match the original
kde_htmldir locations in their sources, and all future CMake migration can go forward
without every set of files having to set kde_htmldir and reset it for 3513 in
another set of patches... (this stuff should be standard anyway -- there is
absolutely no need to have 'kde' or 'tde' in the middle of kde_htmldir)
Because adding the /tde/ (nee /kde/) subdirectory ensures there are no conflicts, real or
imagined, with KDE3/KDE4.
By default KDE4 is hard-coded to install help files to share/doc/HTML. I checked the 4.8.5
source code.
You could modify only kstandarddirs.cpp and the cmake converted packages, but then risk
conflict with KDE. That was my original proposal long ago too. Then I realized the
potential conflict existed and only resolved one problem while creating another. Hence the
eventual comprehensive change of all packages.
Generally, most packagers build TDE to install to /opt/trinity. Most packagers build
KDE3/KDE4 to install to /usr. In that case there are no potential conflicts. Yet nothing
stops packagers from building Trinity to install to /usr.
Short history:
In 3.5.10 kdelibs/kdecore/kstandarddirs.cpp, the path was set to share/doc/HTML/.
In SVN commit 1061230 (3.5.11) the path was changed to share/doc/kde/HTML/. This was the
first attempt to avoid potential conflicts.
In GIT commit 979b0c9a the path was changed to share/doc/tde/HTML/, as part of the overall
renaming project.
As noted, everything now installs correctly in R14. The problem is fixing 3.5.13 SRU. SRU
needs to avoid the same potential conflict. Therefore leave
kdelibs/kdecore/kstandarddirs.cpp as is, leave the cmake packages as is, and update the
autotool packages. Backport the R14 patches.
SRU is not patched with the many renaming efforts and therefore should remain at
share/doc/kde/HTML/, just like currently set in kdelibs/kdecore/kstandarddirs.cpp
The help handbook problem existed right from the beginning in 3.5.13 and never noticed by
anybody. I don't know whether the problems existed in 3.5.12 or 3.5.11. I suspect they
did because the autotool files never were updated to match the change made in SVN 1061230
(3.5.11).
I appreciate the desire to avoid work. Yet once the patches are in place the computers do
all the work.
Your frustration right now is the same I experienced last year when I tripped over this
problem. Small consolation, I know. :-)
Darrell
21 Aug
21 Aug
9:58 a.m.
New subject: [trinity-devel] Why not standardize kde_htmldir='\${datadir}/doc/HTML' ??
On 08/20/2012 12:26 PM, Darrell Anderson wrote:
I see your point, but what else installs in /opt/trinity/share/doc? -- ever?
Your approach does provide a solution for a future /usr install though -- that I
do like...
We can also do a packaging/post-install fix on 3513:
cd /opt/trinity/share/doc/kde/HTML/en
for i in ../../../HTML/en/*/; do ln -s $i; done
or
for i in ../../../HTML/en/*/; do mv $i .; done
(but that type of kludge looks bad...)
The way I looked at it was -- it was the same amount of work either way:
(1) create a duplicate set of commits for 3513 setting everything to /doc/kde/HTML/
(2) attempting to cherry-pick the R14 commits to put everything in /doc/tde/HTML/
or
(3) create a set of commits to standardize the entire GIT tree on doc/HTML.
If we are looking at some future /usr install, then (2) is the correct way to go.
Slavek, can you look at the 4/10, 4/11 commits and see if we can just apply
those to 3513-sru and just pull all the docs in /doc/tde/HTML/? That would also
accomplish standardizing doc locations between R14 and 3513. That would be the
way to go -- all things considered.
Thanks.
--
David C. Rankin, J.D.,P.E.
Why not fix
this once and for all, fix tdelibs, and just set:
kde_htmldir='\${datadir}/doc/HTML'
for all??
That way, instead of patching hundreds of
autotools packages, the original
location in tdelibs is standardized where it should be in
'kstandarddirs.cpp', the CMake files are corrected to match the original
kde_htmldir locations in their sources, and all future CMake migration can
go forward without every set of files having to set kde_htmldir and reset
it for 3513 in another set of patches... (this stuff should be standard
anyway -- there is absolutely no need to have 'kde' or 'tde' in the
middle
of kde_htmldir)
Because adding the /tde/ (nee /kde/) subdirectory ensures there are no
conflicts, real or imagined, with KDE3/KDE4.
By default KDE4 is hard-coded to install help files to share/doc/HTML. I
checked the 4.8.5 source code.
You could modify only kstandarddirs.cpp and the cmake converted packages, but
then risk conflict with KDE. That was my original proposal long ago too. Then
I realized the potential conflict existed and only resolved one problem while
creating another. Hence the eventual comprehensive change of all packages.
Generally, most packagers build TDE to install to /opt/trinity. Most
packagers build KDE3/KDE4 to install to /usr. In that case there are no
potential conflicts. Yet nothing stops packagers from building Trinity to
install to /usr.
Short history:
In 3.5.10 kdelibs/kdecore/kstandarddirs.cpp, the path was set to
share/doc/HTML/.
In SVN commit 1061230 (3.5.11) the path was changed to share/doc/kde/HTML/.
This was the first attempt to avoid potential conflicts.
In GIT commit 979b0c9a the path was changed to share/doc/tde/HTML/, as part
of the overall renaming project.
As noted, everything now installs correctly in R14. The problem is fixing
3.5.13 SRU. SRU needs to avoid the same potential conflict. Therefore leave
kdelibs/kdecore/kstandarddirs.cpp as is, leave the cmake packages as is, and
update the autotool packages. Backport the R14 patches.
SRU is not patched with the many renaming efforts and therefore should remain
at share/doc/kde/HTML/, just like currently set in
kdelibs/kdecore/kstandarddirs.cpp
The help handbook problem existed right from the beginning in 3.5.13 and
never noticed by anybody. I don't know whether the problems existed in 3.5.12
or 3.5.11. I suspect they did because the autotool files never were updated
to match the change made in SVN 1061230 (3.5.11).
I appreciate the desire to avoid work. Yet once the patches are in place the
computers do all the work.
Your frustration right now is the same I experienced last year when I tripped
over this problem. Small consolation, I know. :-)
Darrell
5:50 p.m.
New subject: [trinity-devel] Why not standardize kde_htmldir='\${datadir}/doc/HTML' ??
On Tuesday 21 of August 2012 18:58:01 David C. Rankin wrote:
I see your point, but what else installs in
/opt/trinity/share/doc? --
ever? Your approach does provide a solution for a future /usr install
though -- that I do like...
We can also do a packaging/post-install fix on 3513:
cd /opt/trinity/share/doc/kde/HTML/en
for i in ../../../HTML/en/*/; do ln -s $i; done
or
for i in ../../../HTML/en/*/; do mv $i .; done
(but that type of kludge looks bad...)
The way I looked at it was -- it was the same amount of work either way:
(1) create a duplicate set of commits for 3513 setting everything to
/doc/kde/HTML/
(2) attempting to cherry-pick the R14 commits to put everything in
/doc/tde/HTML/
or
(3) create a set of commits to standardize the entire GIT tree on doc/HTML.
If we are looking at some future /usr install, then (2) is the correct
way to go.
Slavek, can you look at the 4/10, 4/11 commits and see if we can just
apply those to 3513-sru and just pull all the docs in /doc/tde/HTML/? That
would also accomplish standardizing doc locations between R14 and 3513.
That would be the way to go -- all things considered.
Thanks.
Interesting idea. The only thing that interferes with so far quite strictly
held principle not rename k=>t. Please (others), what about this breach rules
do you think?
Thanks
Slavek
--
22 Aug
22 Aug
11:24 a.m.
New subject: [trinity-devel] Why not standardize kde_htmldir='\${datadir}/doc/HTML' ??
On 08/21/2012 07:50 PM, Slávek Banko wrote:
Interesting idea. The only thing that interferes with
so far quite strictly
held principle not rename k=>t. Please (others), what about this breach rules
do you think?
Thanks
Slavek
Let's see what Francios says, but I have thought through this issue regarding a
rename of kde_htmldir from ../doc/kde/HTML/<lang> to ../doc/tde/HTML/<lang>.
I
do not believe there were be any hidden or unanticipated consequences to any
other packages or any other part of the build process. It is just the help dir
locations.
I do TOTALLY are with the strictly held principle for 3513 not to rename k=>t
anywhere it could possibly impact building. After wasting countless hours
chasing k=>t build failures, it is critical that we stick to this principle.
Regarding the khelpcenter doc location, the benefits of the change do
substantially outweigh any risks. Here we standardize the doc location for the
entire GIT tree on ${datadir}/doc/tde/HTML/<lang>. That streamlines backporting
of any future doc changes/additions from R14->3513. We lay the ground work for a
future TDE install in /usr by insuring there are no doc conflicts with kde4 for
all distributions (nobody and no other package will install docs to
${datadir}/doc/tde except TDE. There are no build considerations (i.e. renaming
impacting build of other packages due to a k=>t change. Lastly, nobody cares
what the actual directory name of the doc install location is as long as -- all
the documents show up in khelpcenter. The dir could just as easily be named:
${datadir}/doc/thePlaceToInstallTrinityAppManuals/HTML/<lang> for that matter.
The key is that we standardize the location.
(1) Patch tdelibs to set kdecore/kdestandarddirs.cpp to point to the correct
directory,
(2) Update the CMake files so that the apps building with CMake put the
documents there, and
(3) Update the acinclude.m4 (or admin/acinclude.m4.in) files for all apps that
build with autotools so that they put their docs in the correct place.
Then we are done with this issue once and for all. Darrell's set of commits
should do this for 3513 and require nothing more than cherry-picking. (We need
to make sure (1) above is done in his commits)
Otherwise, we end up with a distro-by-distro set of build-time hacks that are
time consuming and difficult to maintain.
All things considered, I say we do this. Let's get a signoff from Francios and
anyone else you think this change to 3513-sru will impact.
--
David C. Rankin, J.D.,P.E.
12:27 p.m.
New subject: [trinity-devel] Why not standardize kde_htmldir='\${datadir}/doc/HTML' ??
Le 22/08/2012 20:24, David C. Rankin a écrit :
On 08/21/2012 07:50 PM, Slávek Banko wrote:
Hello, I think that changing the "kde" subfolder to "tde" subfolder by
default is a good idea.
As you say, we must ensure that all packages are updated to reflect that
change, including the exotic ones (using scons or whatever else).
A quick thougt about the future install of TDE under /usr: I think the
HTML files conflict is the easiest conflict to solve. We'll have much
more troubles with binary conflicts under /usr/bin ...
Francois
Interesting idea. The only thing that interferes
with so far quite strictly
held principle not rename k=>t. Please (others), what about this breach rules
do you think?
Thanks
Slavek
Let's see what Francios says, but I have thought through this issue
regarding a
rename of kde_htmldir from ../doc/kde/HTML/<lang> to ../doc/tde/HTML/<lang>.
I
do not believe there were be any hidden or unanticipated consequences to any
other packages or any other part of the build process. It is just the help dir
locations.
I do TOTALLY are with the strictly held principle for 3513 not to rename k=>t
anywhere it could possibly impact building. After wasting countless hours
chasing k=>t build failures, it is critical that we stick to this principle.
Regarding the khelpcenter doc location, the benefits of the change do
substantially outweigh any risks. Here we standardize the doc location for the
entire GIT tree on ${datadir}/doc/tde/HTML/<lang>. That streamlines backporting
of any future doc changes/additions from R14->3513. We lay the ground work for a
future TDE install in /usr by insuring there are no doc conflicts with kde4 for
all distributions (nobody and no other package will install docs to
${datadir}/doc/tde except TDE. There are no build considerations (i.e. renaming
impacting build of other packages due to a k=>t change. Lastly, nobody cares
what the actual directory name of the doc install location is as long as -- all
the documents show up in khelpcenter. The dir could just as easily be named:
${datadir}/doc/thePlaceToInstallTrinityAppManuals/HTML/<lang> for that matter.
The key is that we standardize the location.
(1) Patch tdelibs to set kdecore/kdestandarddirs.cpp to point to the correct
directory,
(2) Update the CMake files so that the apps building with CMake put the
documents there, and
(3) Update the acinclude.m4 (or admin/acinclude.m4.in) files for all apps that
build with autotools so that they put their docs in the correct place.
Then we are done with this issue once and for all. Darrell's set of commits
should do this for 3513 and require nothing more than cherry-picking. (We need
to make sure (1) above is done in his commits)
Otherwise, we end up with a distro-by-distro set of build-time hacks that are
time consuming and difficult to maintain.
All things considered, I say we do this. Let's get a signoff from Francios and
anyone else you think this change to 3513-sru will impact.
18 Sep
18 Sep
3:53 a.m.
New subject: [trinity-devel] Why not standardize kde_htmldir='\${datadir}/doc/HTML' ??
Dne st 22. srpna 2012 Francois Andriot napsal(a):
Hello, I think that changing the "kde"
subfolder to "tde" subfolder by
default is a good idea.
As you say, we must ensure that all packages are updated to reflect
that change, including the exotic ones (using scons or whatever else).
A quick thougt about the future install of TDE under /usr: I think the
HTML files conflict is the easiest conflict to solve. We'll have much
more troubles with binary conflicts under /usr/bin ...
As you may have already noticed, all necessary patches have been
backported. I have tested rebuild all Debian / Ubuntu packages and all
looks good.
I hope this was one of last changes before release 3.5.13.1.
Slávek
--
4451
days inactive
4480
days old
6 comments
4 participants
participants (4)
-
Darrell Anderson -
David C. Rankin -
Francois Andriot -
Slávek Banko