Source file sharing between projects

[Matthias Bach]

As a matter of fact a similar approach is used in just about all big software 
companies, and as todays IDEs highly integreate versioning systems this is 
even better than the visual studio source sharing approch.

Am Dienstag, 23. September 2003 18:25 schrieb Roland Krause:
> I've been using KDevelop for a few years now and this is how I do it.
>
> Common functionality goes in libraries.
>
> The libraries are imported as a module into a CVS repository. I prefer
> to include the libraries Makefile.am also as well as the corresponding
> dsp file. The library can now be used in as many projects as you wish.
>
> Example: I have two projects, ArchCad and MechCad, they both use a
> common graphics library GLp. So here is what I do, I have GLP's source
> and header files as well as bitmaps, ui files and everything else that
> it needs under one directory. I cvs import this directory. Done!
>
> I create a KDevelop project ArchCad. It's structure is and
>
> GNU autoconf junk is in archcad
> Sources are in archcad/archcad/
> the library it uses get's checked out to archcad/archcad/GLp
> you get the picture.
>
> Now I add the GLp directory and sources to the ArchCad project. There
> are no copies, the files are already in the right place, still every
> project that used GLp will have it's own copy of the sources.
>
> No need to recompile GLp everytime because dependecies are handled by
> make. If I make changes to GLp, which I do often while I develop a
> program, I check the changes into the CVS repository.
>
> Further, I edit the ArchCad projects Makefile.am to augment the include
> path with GLp and add the library libGLp (also in Makefile.am). I can
> not be bothered to really learn autoconf that's why I edit Makefile.am.
>
>
> This works well for me, all my projects use Qt, OpenGL and all kinds of
> other libraries (like QextMDI and Qwt), they all use the identical
> structure under windows (with dsp files checked in the repository).
>
> CVS is your friend and the key to your success. If you cant be bothered
> learning CVS get cervisia (KDE UI client) or WinCVS and spend 15
> minutes with the O'Reilly CVS book, that's all you need.
>
> Good luck,
> Roland
>
> --- Mickael Faivre-Macon <mickael at easyplay.com.tw> wrote:
> > Hi Tarjei,
> >
> > Thanks for the help. I appreciate it.
> >
> > But I am familiar with the concept of libraries (they exist in the
> > Windows world too, we are part of the same species, programmers ;-).
> > I
> > am just not familiar with Linux and KDevelop yet.
> >
> > It is not a matter of misconception but a matter of choice. I am
> > self-employed, working on my little projects for my little customers.
> > I
> > am working every day with these home-made libraries and if I had to
> > recompile the library *and* the project every time I change something
> > in
> > the lib, I would spend my life reload the projects and compiling.
> > (Unless KDevelop 2.1 or Gideon (I am using KDevelop 2.1) handles
> > multiple projects ? I don't think so).
> >
> > As I said - and it seems I am not the only one (see previous post by
> > Rolf Thunbo) - KDevelop can not handle symbolic-links. So here I am,
> > still with my sources spawned in every projects dir...
> >
> > I do consider using libs, if KDevelop can handle multiple projects,
> > some
> > day, but I would prefer to have a option to be able to include my
> > shared
> > source files into all my project. It is just handy. One day, I will
> > distribute my lib to the World and beyond, but not today.
> >
> > Thanks again for your time all of you... :)
> >
> > Mickael
> > French guy in Taiwan
> >
> > >I think there's a slight misconception here. If you have utility
> >
> > classes
> >
> > >that are used across a multitude of projects, then those utility
> >
> > classes
> >
> > >belong in a utility library which you should use "externally" in
> >
> > your
> >
> > >other projects. If you want to develop and maintain those utility
> > >classes using KDevelop, then you should create a separate project
> >
> > for
> >
> > >them. You should add any needed headers to be installed with that
> > >package. Whenever you do a new version of your utility library, you
> > >should build and "make install" it, for instance to /usr/local.
> > >
> > >When you want to use your utility library in other projects, you
> >
> > should
> >
> > >just #include the headers you need, and link your project with your
> > >utility library. Your library files should not be included in other
> > >projects at all, just like you would never include any parts of the
> > >standard library into your project.
> > >
> > >Cheers,
> > >--
> > >Tarjei
> >
> > ---------------------
> > Free SMS: http://organizer.easyplay.com.tw/
> >
> > -
> > to unsubscribe from this list send an email to
> > kdevelop-request at kdevelop.org with the following body:
> > unsubscribe your-email-address
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> -
> to unsubscribe from this list send an email to
> kdevelop-request at kdevelop.org with the following body: unsubscribe
> »your-email-address«

-- 
Matthias Bach
cyberpunx at gmx.net
http://www.marix-world.de


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