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

[Andreas Pakulat]

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.

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.

Andreas

-- 
Snow Day -- stay home.