<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 10, 2014 at 7:35 PM, Sven Brauch <span dir="ltr"><<a href="mailto:svenbrauch@googlemail.com" target="_blank">svenbrauch@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Monday 10 February 2014 22:04:48 Sergey Kalinichev wrote:<br>
> To the point, where to store information on the file system or in kdev4<br>
> file?<br>
</div>I would definitely vote for file system, for the reasons discussed.<br>
<br>
For detecting and wrapping it into a GUI, I would say:<br>
<br>
 - GUI is not a problem if we have a "one-dimensional" file format like now,<br>
i.e. just list of dirs separated by \n. Sounds very easy to wrap into a GUI<br>
with few chances to screw anything up.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - For detecting the file, I would just keep going upwards from the source<br>
location and look for the file. That's what git does too and I think it works<br>
well enough for all non-crazy use cases.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>Anyway, just my 2 cents.</div><div><br></div><div>Andreas </div></div></div></div>