Review Request 128012: Check for an existing out-of-source build dir

[Alex Richardson]

> On June 2, 2016, 10:26 p.m., Milian Wolff wrote:
> > project/helper.cpp, line 221
> > <https://git.reviewboard.kde.org/r/128012/diff/3/?file=465463#file465463line221>
> >
> >     I feel really bad with this... Yes - it's powerful, but it's also overkill, no? Who would ever write such a script?
> 
> Kevin Funk wrote:
>     I also think the custom script is overkill. We should just default to sane default paths.
>     
>     +1 for discarding this idea. Sorry, Rene.
> 
> Alex Richardson wrote:
>     I would use this feature but I'm not sure running a custom script is the best solution (it is however quite easy to implement). No one would ever use it because it is very hard to discover. Maybe there should be an option in the settings menu.
>     
>     I have the following structure for my projects: source dirs are in /data/sources/ and build is in /build/ (separate partition because I don't have enough space on my SSD). It would be quite nice if I wouldn't have to manually set the build directory for every new project that I open.
>     
>     If I had known that kdevelop replaces /src/ with /build/ (as I found out by reading this diff) I could have come up with a different hierachy that wouldn't require running a custom script.
> 
> Kevin Funk wrote:
>     Yes, I don't think this is super discoverable as is (using an external script).
>     
>     I think what *could work* is a line edit in the settings where can specify the translation from source directory to build directory (via string having the project name as placeholder). E.g. it would be "/build/${projectname}" in your case, and would default to something along "${projectpath/\/src/\/build}" (undecided about the syntax, can't think of anything more appropriate right now than Bash's string replacement syntax).
>     
>     Anyway, I don't think it needs to be / or should be an external script (way to complex).
> 
> René J.V. Bertin wrote:
>     Evidently I have done *nothing* at the moment to make this discoverable, and evidently a final implementation would have something to attract the user's attention to the fact that this feature exists. One easy way would be in the project settings, a place to (wait for it) select a script that returns the build directory for a given source directory, and optionally a few choices for where that script will be searched (on $PATH; relative to the source directory; at a specific location).
>     
>     I did think of a special syntax myself, but realised very quickly that if you really want to do that right you'd end up either using an existing script language, or you suppose users are fluent in `awk` or you pick a solution in which you basically type the whole script in a text field and then use some `sh` variant to execute it. The former solution is evidently quite complex to implement; let's not even talk about awk, and with the latter, well, you can just as well read the script from disk even if KDevelop already has an external scripts implementation.
>     
>     The problem with a simple translation is that it will typically not be sufficient at the level of the method we're patching. For instance, you may not want to pick `../build` if that directory exists but doesn't hold a CMakeCache and/or Makefile. That's a choice you cannot make at this level, but that a script *could* make, possibly on the basis of additional criteria that are purely local.
>     I see it this way: a script *can* be complex, but doesn't have to be. Generic logic that works well for everyone is going to be complex too, and probably (too) brittle. At the very least each project importer that calls this function would have to provide a function that checks the result of the user-supplied transformation to determine whether it can be an acceptable choice.

QtCreator has a default build directory setting which can use lots of variables including `{JS:....} Evaluate simple JavaScript statements. The statements may not contain '{' nor '}' characters.` Maybe we should use a similar approach?


- Alex


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128012/#review96160
-----------------------------------------------------------


On May 25, 2016, 9:24 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128012/
> -----------------------------------------------------------
> 
> (Updated May 25, 2016, 9:24 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdevplatform
> 
> 
> Description
> -------
> 
> When importing a new project, check if it already has a pre-existing out-of-source build directory, and propose that as the build directory in `KDevelop::proposedBuildFolder()`.
> This is comparable to proposing to put the build folder alongside an existing `src` directory (but has priority over that rule).
> 
> 
> Diffs
> -----
> 
>   project/helper.cpp 6df9f90 
> 
> Diff: https://git.reviewboard.kde.org/r/128012/diff/
> 
> 
> Testing
> -------
> 
> Builds and behaves as expected.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160603/8a9a102e/attachment-0001.html>