Review Request 125732: Removing the Build Set

Andreas Pakulat apaku at gmx.de
Thu Oct 22 10:02:26 UTC 2015 


> On Oct. 21, 2015, 7:08 a.m., Andreas Pakulat wrote:
> > Since the BuildSet has always been controversial even while I was still hacking KDevelop I think this is a good step. But I do want to highlight another usecase that I happened to use within kdevelop: Build multiple targets within a single project (and their dependencies) but not 'other' stuff. I've been using this to concentrate working on a particular small set of kdevelop plugins that are related but don't depend on each other. Examples are: the vcs plugins or the buildsystem plugins.
> > 
> > That gets more cumbersome (unless the structure in the filesystem changed meanwhile creating such grouping of plugins) without a buildset.
> 
> Aleix Pol Gonzalez wrote:
>     As I see it, wanting to build 2 elements in the tree rather than the whole tree is a workaround and usually leads to errors.
>     
>     Personally, I've solved that by using `ninja` instead of `make`.
>     We could try to bodge that use-case into the new approach (by making it possible to set the new build item with 2 selected items), but I'm afraid it wouldn't be very intuitive anyway.
> 
> Andreas Pakulat wrote:
>     I don't see what ninja vs. make has to do with this, nor do I understand to what errors such a use-case would lead.
>     
>     I think requiring users to build a whole project even though they work only on one or two smallish parts is not very nice of an IDE. This may not be an issue with kdevelop which builds in a few seconds (at least on modern hardware with 8 core's, 64G RAM and ssd's), but a non-trivial project may take dozens of minutes or even take hours to build. At the same time designing the cmake files so one can load just a subtree is not trivial either I think (or does kdevelop have provisions for this meanwhile, sorry I'm too much out of touch I guess). So an update of a header file that rebuilds core parts, but does not touch the interfaces a set of plugins uses, would cause a long wait time before the user can resume his work.
>     
>     Though maybe the use-case can already be covered quite nicely by simply manually changing the project configuration's build command to include the necessary make or ninja arguments to build just a set of targets. I always thought its nice though to be able to select targets in a ui as then I don't have to go hunting for them in a commandline, but I agree the UI I came up with back then (or we came up with, can't remember) is not quite the easiest to understand.
>     
>     Well, I'll shut up now, just wanted to make sure all use-cases that where originally intended are considered :)
> 
> Milian Wolff wrote:
>     Ninja helps as it's so much faster than make, you don't need to run it in a subfolder of a project. And with CMake or anything else - you only build what was changed, no? I don't see how it helps to run make in a subfolder, which often just gives you the same as running ninja globally, but additionally offers you a good way to shoot yourself in the foot with ABI incompatibilities...
>     
>     Furthermore, this is about having a simple GUI to solve the common case. As you mention, there are ways to get the uncommon behavior done as well. Global make config for the project is one option, context menu on a folder another. And I think that folder could also be put into the selection, no? Just like a target? So one could even say: if you want special behavior, add a custom target?
>     
>     Regarding the UI experiment:
>     
>     * What about building the current project by default? 
>     * Could we use the same place to show the currently active run configuration? Should we?

I'm not concerned about how exactly one builds only part of a project - wether its a cd <somesubfolder> && make or ninja <some-target>. And yes, with modern buildsystems (provided the project does not setup its rules incorrectly, which can be tricky) only what has changed is being rebuilt. However such a change may not affect the area I'm working on right now (it causes a rebuild of a larger part of the project that is not related to what I'm doing and does not affect me) and then I get to wait until all that is built if I can only build whole projects.

If building only part of a project lets a user run into ABI incompatibilities inside a single project, then there are missing dependencies in that project that ensure that things get relinked as necessary when the ABI changes due to some part being rebuilt.

Being able to put a folder into the new simpler ui is fine, but what if I have 2 folders (or targets for that matter since ninja exposes only those) that I work on (see my initial example)?


- Andreas


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


On Oct. 20, 2015, 11:56 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125732/
> -----------------------------------------------------------
> 
> (Updated Oct. 20, 2015, 11:56 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdevplatform
> 
> 
> Description
> -------
> 
> For years my task in KDevelop has been to advertise how useful it is to have the projects loaded.
> 
> I've always had a hard time at explaining how the build set works, and many people have told me they consider it too complex. If anything, I can agree that it has a very prominent space in the UI (especially being in one of the most used ToolViews).
> 
> With this new approach we have some uses that aren't available, but I like it because it's slightly more straight to the point and it hides the complexity elsewhere.
> 
> The idea is that we will have instead just 1 item to be built/installed every time (instead of N). This is the most common use-case and that's covered.
> The reason I always understood having many of them, is that sometimes you want to have a project installed before installing another one. (e.g. you are a konqueror hacker and need kparts installed every time you build konqueror). To solve this I added a project configuration page where people can add the dependencies. These will be installed every time the user builds the currently selected item.
> 
> 
> Diffs
> -----
> 
>   interfaces/iprojectcontroller.h 0e232db 
>   plugins/projectmanagerview/CMakeLists.txt cd045e1 
>   plugins/projectmanagerview/projectbuildsetwidget.h ade1cfc 
>   plugins/projectmanagerview/projectbuildsetwidget.cpp 7108a92 
>   plugins/projectmanagerview/projectbuildsetwidget.ui 5de669e 
>   plugins/projectmanagerview/projectmanagerview.h 07e24d6 
>   plugins/projectmanagerview/projectmanagerview.cpp fd8bc02 
>   plugins/projectmanagerview/projectmanagerview.ui 3b2a78a 
>   plugins/projectmanagerview/projectmanagerviewplugin.h d2d7109 
>   plugins/projectmanagerview/projectmanagerviewplugin.cpp 04af3a4 
>   project/CMakeLists.txt 2e6fe7d 
>   project/projectbuildsetmodel.h bce29fa 
>   project/projectbuildsetmodel.cpp 286f668 
>   project/projectmodel.cpp 841105d 
>   shell/projectcontroller.h 188184c 
>   shell/projectcontroller.cpp 766c280 
>   tests/CMakeLists.txt bc6632b 
> 
> Diff: https://git.reviewboard.kde.org/r/125732/diff/
> 
> 
> Testing
> -------
> 
> Seems to just work, I've been using it for a couple of days and I'm not annoyed. There might be quirks but my proposal is to get it in master for 5.1, it's not pressing to have it.
> 
> 
> File Attachments
> ----------------
> 
> GUI
>   https://git.reviewboard.kde.org/media/uploaded/files/2015/10/20/d5a791a1-45fc-4ec0-815f-68db0f7f2854__kdevelop-build.png
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

More information about the KDevelop-devel mailing list