2012/11/13 Amit Kulkarni <amitk...@gmail.com>:
>>> >> 1) adjust kde3 with /usr/local/kde3/* (i.e include, libs, bin) + have
>>> >> kde4 with /usr/local/kde4/*. both independent. is it too hard to add
>>> >> this for kde3?
>>> > I don't know. You tell me.
>>>
>>> Not too hard for KDE 4. But I still hope to find better way than this
>>> "/opt"-ism.
>>>
>>> My personal goal is to make KDE 4 co-build with KDE 3, and to make
>>> libs and pimlibs from KDE 4 co-exist with KDE 3. But I didn't even
>>> started moving in that direction, there is too much other work.
>>
>> I did a bit of that work, like actually moving the kde3 libs out of the
>> way into /usr/local/lib/kde3... having kde3 use libtool also helps picking
>> up the right libraries (I have to fix the one kde package that still wants
>> gnu libtool though).
>>
>> I won't object to *finishing* that in tree *if we have a plan*. That means,
>> preferably import the kde4 parts after the directories are mapped out so
>> that there's little conflict with kde3.
>>
>>> I have some crazy ideas like porting KDE3 to CMake, but before talking
>>> loud about them sound I should try to try starting myself.
>>
>> No, that's crazy. You said trinity was hard to do. Changing kde3 to cmake
>> more or less requires redoing what the kde people did between kde3 and kde4
>> and that was a LOT of work.
>>
>> *most* of the autoconf stuff in kde3 is reasonably easy to move around. It
>> may require testing, obviously...
>
> Ok its option 1: separate out kde4 and kde3 to use different folders
> under /usr/local both for simultaneous building and running. I will
> submit the ports needed for kde4 and then Vadim/me finish KDE 4.9.3 by
> relocating to different folders in /usr/local (4.9.2 doesn't have
> working pim). Then before the kde4 merge, the kde3 stuff has to be
> shifted to different folder.
KDE 3 is already separated enough, thanks (a lot!) to Marc. I've
thought to follow the same scheme when started hacking on KDE4 but it
was a bit harder. Even using "${PREFIX}/libexec" became a challenge
due to many hardcoded paths. :(
--
WBR,
Vadim Zhukov
