Subversion repository structure (was: trunk/kdeedu/klettres)

[Alexander Dymo]

On Sunday 20 February 2005 11:04, Andras Mantia wrote:
> I'd like to crossposts to quanta-devel as well, as some of us are not
> subscribed to kdevelop-devel and might miss it.
Ok.

> On Sunday 20 February 2005 00:39, Alexander Dymo wrote:
> > Matt is right. We've been following KDE release schedule since KDE
> > 3.2 but that is not obligatory for us.
> It's not obligatory for anybody, but do you want to follow it for the
> next release (4.0) or not?
I'm not sure. At least I'm not sure for KDevelop. But we _can_ make sure
that at least kdevplatform is released among with KDE.

> > 1) Will kdewebdev be inside trunk/KDE/ or will it be a separate
> > module trunk/kdewebdev?
> I'd like to keep it under tunk/KDE. This is because kdewebdev has other
> (standalone) applications, like the HTML image map editor, the XSL
> debugger or the link checker. I'm not including KFileReplace and
> Kommander here as they are not completely related to web
> development. ;-)
>  Quanta should remain there as well. Just that to have Quanta, you
> require the KDevelop platform. Now about the shell I have mixed
> feelings. The best would be to have a good general shell, so we don't
> have to write and maintain to shells in different places.
My personal feelings are that it's better to have a common shell. Both Quanta
and KDevelop currently work around tons of same shell-related problems and
tons of same shell-related features (editor integration/interaction to name
just only one and most painful).

> > 2) Where shall the "platform" module be in ("trunk/KDE/kdevplatform"
> > My answer:
> > We can create one root module for all development applications, like:
> > "trunk/kdedev"
> This may have the problem that there are other development related
> applications partly in kdewebdev and partly in kdesdk.
Heh, kdesdk... Actually I think when we have kdevplatform we will move
all parts of kdesdk we depend upon to kdevplatform. Namely: svn kioslave,
cervisia part and dcopservice.

> > Why do I suggest one module for all development applications? Well, I
> > have several good reasons:
> > 1) We can schedule kdedev releases either with corresponding KDE
> > releases or on our own.
> I don't see that we (the Quanta team) would like to release separately
> from KDE in the near/middle-term future.
Ok, I see.

> > 3) kdedev would be the best place to put platform stuff. We can't
> > really put the platform into kdelibs just because platform is not
> > only libraries but also common plugins.
> Right. My proposal would be to have a separate modulefor the platform
> and common plugins, like:
> trunk/KDE/kdevplatform (contains plugins and the platform)
> trunk/KDE/kdewebdev (our stuff)
> turnk/kdevelop (your stuff)
Or trunk/KDE/kdevelop ;) KDevelop has been a part of KDE distribution
for a long time (despite of development problems in 2.x and delay of 3.0).

> The latter two requires the first one. This is inter module dependency,
> but might have some good benefits compared to the all-in-one solution.
> There are two possible problems with that one:
> 1) packaging: 
> The kdevplatform part must be self contained, packagable and 
> compilable alone. This is why if it's really alone might make more
> sense.
I agree that having it under KDE/ allows applications both inside KDE/
and inside trunk/ have dependencies upon kdevplatform.

> 2) CVS(ok SVN ;-)) users: what if somebody wants just Quanta or just
> KDevelop from the repository? I cannot tell him to check out the mega
> module kdedev and only use half of it. I know it's a pain for many to
> download such a big amount of data (and have it on the disk sitting
> without you ever using it). And I certainly don't want to give them a
> crash-course about how to get it in pieces.
Anyway, kdevplatform module will make it slightly harder for users to 
compile quanta/kdevelop. But I can't see any problems with that.
For example, we will just place two download links at the website:
one for kdevelop.tar.bz2 and another for kdevplatform.tar.bz2.

> 3) Releases: what if KDevelop wants a different release schedule from
> Quanta? How can it be tagged/branched? Having the platform in a
> separate module (which always follows the KDE release cycle) makes this
> easier. If you decide to release the next KDevelop IDE (with
> C++/Ruby/whatever support) differently from KDE, we could still release
> Quanta with KDE.
Agree.

> 4) This is something different and that it's a problem in both cases,
> namely that if we convert Quanta into a plugin, I need to install it
> every time to try out my changes, am I right? Now how do you (plugin
> writers) deal with this cases? I'd like to have the possibility to just
> press Execute program, it builds the plugin, runs the shell and the new
> plugin is loaded, not the old one which is installed.
Heh, yes, that's always a problem for KDE plugins. You can see a lot of
threads in k-d or k-c-d about that proble.
I run make install onto a separate directory (like ~/kdevelop) and use
KDEDIRS=... kbuildsycoca ... && kdevelop ... to run the application.
All the commands above can be set in the project options inside the IDE.
So all you should do is to run additional "make install" phase.
Also with recent KDevelop you can have custom build menus for automake
subprojects with custom commands (I use "make && make install" and
"make && sudo make install").

Ok, so for now we have this layout:
trunk/KDE/kdevplatform (contains plugins and the platform)
trunk/KDE/kdewebdev

trunk/kdevelop
or
trunk/KDE/kdevelop

Any opinions?

-- 
Alexander Dymo
ICST Department, National University of Shipbuilding, Mykolayiv, Ukraine