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.