how to seperate project files from source files in different dirs?

[JeDi]

On 8/1/07, Andreas Pakulat <apaku at gmx.de> wrote:
> On 01.08.07 19:07:34, JeDi wrote:
> > On 8/1/07, Andreas Pakulat <apaku at gmx.de> wrote:
> > > On 01.08.07 15:05:28, JeDi wrote:
> > > > On 8/1/07, Andreas Pakulat <apaku at gmx.de> wrote:
> > > > > On 01.08.07 20:26:26, shizheng wrote:
> > > > > > I'm new to kdevelop, so I just can't figure it out that project files
> > > > > > and source files
> > > > > > must be arranged in the same directory :( Could you please explain it to me?
> > > > >
> > > > > Its implemented like that, kdevelop will put 2 of its files into the
> > > > > source directory and there's  no easy way to change that and also
> > > > > probably nobody who wants to write the code for that.
> > > >
> > > > I understand why someone would do this. We are a research company that
> > > > write code that has to run on very different setups and architectures,
> > > > most of them using different build environments. If all the project
> > > > files of each build environment would sit in the source code
> > > > directories, it would be a mess to manage.
> > > >
> > > > We have a directory setup like this:
> > > > - bin/win32_debug, bin/linux_debug, ... -> shared libraries and
> > > > executables will be output to these paths
> > > > - lib/win32_debug, lib/macos_release, ... -> link libraries for
> > > > different platforms will be output to here if necessary
> > > > - src -> source code (headers and source files), in a subdirectory per
> > > > library/executable
> > > > - buildenv/vs2005, buildenv/codeblocks, ... -> a subdirectory for each
> > > > build environment. All project files and other build environment
> > > > specific files reside here.
> > > >
> > > > This way, we can easily manage our different build environments
> > > > without having to clutter the source directory. In KDevelop, this is
> > > > very hard to accomplish. Project files should contain files with
> > > > relative paths to the directory where the project file sits.
> > >
> > > I still fail to see the problem: If you copy around your project tree's
> > > including the different build environment you're doing something wrong
> > > anyway. If you use a revision control system you shouldn't check
> > > any of the kdevelop specific files into it, thats just not supported.
> >
> > Since when is that valid?
>
> At least since KDevelop3.0.
>
> > Do you mean that all the developers working on your projects have to
> > maintain their own project settings like the file list and such? That
> > would be an enormous waste of developer time resources.
>
> Exactly. However its not really a waste of resources, as KDevelop does
> have a well-working import project which provides you with a working
> project really fast.
>
> > In my opinion, the _project_ file should only contain settings that
> > are common for the _project_, like build parameters, file lists,
> > dependencies, ..., and that file actually belongs in version control.
> > All user-specific settings should reside in a separate file that is
> > ignored by the revision control system.
>
> Right, but thats not the case for KDevelop3.
>
> > > > This is probably a design mistake, and not very hard to live with if
> > > > you only use kdevelop as build environment, but for a next major
> > > > release like KDevelop 4, I would definitely support this. For us (and
> > > > probably a lot more companies), this is the reason why we don't use
> > > > kdevelop for many projects (we do use it for linux-only projects,
> > > > because it is a great application).
> > >
> > > Well, so far the .kdev4 file will end up in the same directory as the
> > > project itself (at least there's no support yet for a different
> > > directory for the project), however that file is supposed to be checked
> > > into a version control system in KDevelop4. So it will contain only very
> > > little information, like the type of buildsystem, the projects name and
> > > eventually the version control system to use. If a projectmanagement
> > > plugin needs a filelist to determine which files are project files, that
> > > filelist will go into a hidden directory in the same path as the .kdev4
> > > file. And that subdir is also not supposed to be shared among developers
> > > or different systems.
> >
> > That is too bad... If we would work like that, all our developers had
> > to maintain their own project settings for kdevelop, Visual Studio,
> > CodeBlocks, ... I just can't see the advantage in that.
>
> Well, I don't know about the other projects but for KDevelop you have
> very little information in the kdevelop project file. I don't know about
> CodeBlocks, but VS maintains its own buildsystem, KDevelop doesn't do
> that, it builds on top of an existing buildsystem.

Yes, off course, then the build system files should have support for
using source files in another directory, but that isn't kdevelop's
problem. So it probably won't be that much of an issue.


> Let me give you an example: I recently branched out a part of KDevelop4
> sources, all I had to do to get a kdevelop project for that was Project
> Options->Import existing project, let it populate the project filelist
> by giving it a few shell-like parameters of which filetypes I'd like to
> see in the project and thats it. (Well I needed to set the binary in the
> project options, but thats it).
>
> And I doubt that you create a project every other day, if you do so this
> of course doesn't work.

Well, we are working in about 20 different projects, being a research
facility with a very broad spectrum of interests :-) So we probably
need this more than the average company or hobbyist.

Greetz,
JeDi