kdevelop and cvs

Caleb Tennis caleb at aei-tech.com
Mon Feb 24 19:17:11 GMT 2003


On Thursday 20 February 2003 06:19, you wrote:

> first: what are the files that really need to be added to cvs
> repository? i mean. should the admin directory be added? should
> Makefile.am ? and so on... i need to produce a cvs version that is
> compilable from everyone which have autotools. Not every developer involved
> in my project uses kdevelop, so i need an uniform management to prevent
> misuse. As far as i understand, Makefile.am is automatically created by
> kdevelop from the kdevprj file, so it should not be added to cvs. What
> happen if some developer which doesn't use kdevelop need to create a new
> directory or file? it should modify the .kdevprj by hand, i guess... how
> now can recreate Makefile.am files?

Following KDE's lead, you should put the Makefile.am and no other Makefile 
into the repository.  While kdevelop 2.1 automatically creates Makefile.am, 
you will need it in the repository so your developers that DO NOT use 
kdevelop can use it.

You will need the admin directory stuff in the repository only if you're using 
the given templates to create your code.  If you're using a non kde based 
automake project you probably won't need it.

> second: I need to check for other libraries on the target system. Exactly,
> i need to check for libqwt (c++), libblas and liblapack (fortran).
> reading on the faq, i noted that changes should be added to
> configure.in.in. Good. My question is: as the best approach, should i check
> for the specific file (ex: qwt_plot.h) or try to compile and link some
> simple code? Where can i find a simple application built with kdevelop that
> uses other checks? as suggested, i tried to create a kde-opengl project,
> but i dont' have that entry.

You should look at the way KDE handles this.  It's a bit tricky to understand, 
but there are checks that are done to see if certain libraries exist.  In 
many cases it looks for header files and attempts to do small compilation to 
verify if the headers are good.

> pointers to documentation and simple example applications greatful
> appreciated.

I don't know of much documentation that exists for this type of work, but 
http://developer.kde.org has some good references to be sure and check.

> i use kdevelop 2.1.5 for kde3.1, automake 1.5 and autoconf 2.53

Should be suficient for what you're trying to do.

Good luck,
Caleb


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



More information about the KDevelop mailing list