Le 22/08/2012 20:24, David C. Rankin a écrit :
> 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.
>


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