Break Custom Buildsystem Plugin apart into 2 pieces.

[Milian Wolff]

On Monday 10 February 2014 20:49:40 Andreas Pakulat wrote:
> Hi,
> 
> On Mon, Feb 10, 2014 at 7:35 PM, Sven Brauch 
<svenbrauch at googlemail.com>wrote:
> > On Monday 10 February 2014 22:04:48 Sergey Kalinichev wrote:
> > > To the point, where to store information on the file system or in kdev4
> > > file?
> > 
> > I would definitely vote for file system, for the reasons discussed.
> > 
> > For detecting and wrapping it into a GUI, I would say:
> >  - GUI is not a problem if we have a "one-dimensional" file format like
> > 
> > now,
> > i.e. just list of dirs separated by \n. Sounds very easy to wrap into a
> > GUI
> > with few chances to screw anything up.
> 
> That does not work for includes and defines that easily (in the same file).
> So you'd introduce yet another file. Also using a different format than the
> custom buildsystem uses now means the argument of 'changing little so
> cannot screw up anything' is void too. The custom buildsystem plugin has to
> be changed.
> 
> >  - For detecting the file, I would just keep going upwards from the source
> > 
> > location and look for the file. That's what git does too and I think it
> > works
> > well enough for all non-crazy use cases.
> 
> Yes, except that you should not necessarily stop at that path but go up
> further. And then where to stop? That is, I don't want to setup the Qt
> includes for each directory in my project, but I may want some include dirs
> for only some of the subdirs but also need the Qt includes.

Exactly, it's easy to find include paths for files in a project, but if you 
want to configure include paths for files outside of a project things get 
messy.

> I also think that kdevelop should try to not litter the project directory
> with tons of files (yes, thats an exaggeration). There already is an
> existing mechanism for storing project configurations and that should be
> used if you have a project.

True.

> Now if you do want to support defining includes and defines for files
> outside of projects (frankly, I'm not sure thats really an important
> usecase for an IDE, you'd have to setup a way to compile things as well as
> thats not easily doable inside kdevelop and suddenly you got two files in a
> dir already again), you could fallback to that if you cannot determine the
> project for the current file and then use the .kdev_include_path.

True again. Lets just extract what we have in the custom build system into a 
generic plugin to make it available for all project managers. Then, as Andreas 
proposes, lets keep the .kdev_include_path fallback as-is for files outside 
the project.

> I believe one of the main reasons for keeping a simple file format was to
> make it editable outside kdevelop since you cannot easily invoke the
> include-path-resolver inside kdevelop. If there is a proper way to get an
> editor for the file inside KDevelop, in particular one that triggers
> reparsing of the relevant project/file, I'm not sure thats of any
> importance anymore either. (the kconfig file is not easily editable with a
> text editor).

Yep. Also, this is required for things like duchainify, which does not (yet) 
load any projects and thus does not get any includes/defines from there. But 
that is imo a limitation in a test-only tool and should not hold us back. I 
wanted to extend duchainify to load projects for ages anyways...

Bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de