Break Custom Buildsystem Plugin apart into 2 pieces.

[Andreas Pakulat]

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.

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.

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.

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).

Anyway, just my 2 cents.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140210/e22d0054/attachment.html>