KDevelop 3 and KDE CVS Repository

[Gary Cramblitt]

On Thu, 20 Nov 2003 10:25:50 +0200 (EET)
<cloudtemple at mksat.net> wrote:

> KDevelop project templates are the templates for standalone builds. If you work 
> on kdenonbeta, it is a good idea to checkout kdenonbeta (you may do it with -l switch 
> as well) and then import it to KDevelop. After that the only thing you must do is to 
> create a subproject containing your application and a corresponding subproject with 
> your documentation. This could have solved almost all your problems with the build  
> system. 

Sure wish I had known about this before I started my project.

>  
> For example, to work on Kugar (the part of KOffice) I do 
> cd /develop/kde 
> cvs co -l koffice 
> cvs co koffice/doc 
> cvs co koffice/libs 
> cvs co koffice/mimetypes 
> cvs co koffice/kugar 
>  
> The same way is to checkout all KOffice like: 
> cd /develop/kde 
> cvs co koffice 
>  
> Then I open KDevelop and import /develop/kde/koffice dir or simply 
> /develop/kde/koffice/kugar. 
>  
> Let's imagine I need to add an application to KOffice, say myapp. 
> Then I'd do: 
> cd /develop/kde 
> cvs co koffice		(or only necessary dirs) 
> open KDevelop 
> import /develop/kde/koffice dir 
> go to automake manager and add subproject called "myapp" 
> go to doc subproject and add a "myapp" subproject there 
> then simply click build everything or only "myapp subproject" 

(I've removed the "-l" options from two of your commands, where I don't
think you meant to have them.)

This doesn't sound very different from what I described in the wiki.
MyApp is automatically seen as a subproject of kdenonbeta because of the
existence of kdenonbeta/myapp/Makefile.am.  Yes?  Or perhaps there is
more to subprojects I don't understand?  Subprojects aren't documented
very much in the KDevelop Handbook.  They're mentioned in the chapter on
Automake Manager.

What might be needed tho is a section in the wiki document that
describes your technique when first starting out on a new project.  In
other words, instead of creating the project in a separate directory and
then moving it to the CVS working directories, start out by checking out
kdenonbeta (or whatever) as you describe, importing it, then creating a
subproject. In theory, this would avoid having to later go through the
process I describe to move the project into the CVS working directories.
 As you save, it saves a lot of problems.

I haven't seen anybody comment on the "collapsing" of the directory
structure I described in the wiki.  Is this good, bad, user optional?
When I look through the various projects in the CVS repository, most
seem to have this "collapsed" structure.  Perhaps this is because most
people are using your technique?  I can see I'm going to have to play
with this more to get a fuller understanding of the various techniques
and what KDevelop is doing/does.  One thing I'm wondering about for
instance, is: when I create a subproject, will KDevelop create a
Makefile.am with the "SUBDIRS = $(TOPSUBDIRS)" problem?

I have a feeling this is all very mysterious to most KDevelop/KDE
developers, but maybe I'm just an ignorant newbie. :-)

Thanks for the input very much,
Gary Cramblitt


-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«