Message: previous - next
Month: August 2012

Re: [trinity-devel] Why not standardize kde_htmldir='\${datadir}/doc/HTML' ??

From: "David C. Rankin" <drankinatty@...>
Date: Wed, 22 Aug 2012 13:24:15 -0500
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

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

(2) Update the CMake files so that the apps building with CMake put the
documents there, and

(3) Update the acinclude.m4 (or admin/ 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.