[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Bug or feature ? Edited project-generated targets are saved
From:       Kåre_Särs <kare.sars () mailbox ! org>
Date:       2024-02-10 10:51:06
Message-ID: 3283207.44csPzL39Z () sars-xps-13-9370
[Download RAW message or body]

Hi,

On torsdag 8 februari 2024 23:39:35 EET Alexander Neundorf wrote:
> Hi,
> 
> On Mittwoch, 7. Februar 2024 23:02:36 CET Alexander Neundorf wrote:
> > Hi,
> > 
> > the project plugin can generated targets for the build plugin.
> > The entries in the build plugin are editable by the user.
> > This may be useful, e.g. to change the "-j8" flag for make, or maybe add
> > some other option.
> > 
> > But, such a change is also saved. And from that moment on, it seems kate
> > always loads the saved, edited targets, no matter whether the project
> > plugins generates different targets now (e.g. because the cmake files for
> > that project have been changed).
> > 
> > To me this feels like a bug.
> > I think it may be useful that the build commands are editable, it provides
> > some flexibility. If they were not editable at all, this would be also Ok
> > for me.
> > But that my edits are saved and then override the "new" targets from the
> > project plugin feels like a bug, the targets are then not up to date
> > anymore with the current state of the actual project.
> 
> Ok, I found it, it's a feature:
> https://invent.kde.org/utilities/kate/-/commit/
> 678e8a3bd98d5110da21091aefef00aa9cf3097f[1]
> 
> TBH, this feels like a bug.
> I add a new target in cmake, and it doesn't appear in the build plugin.
> I remove a target, it's still there.
> There is no indication that this was read from a file, and that the input
> from the project plugin is ignored now.
> 
> I understand the motivation: the user changes something, so this should be
> kept. Nevertheless, how about removing this questionable feature ?
> This would make the code a bit simpler.
> 
> Or, keep it, but instead of storing the full override, just store what has
> been changed ? E.g. "target foo moved 2 rows up" or "command target for
> target bar edited" etc. and then apply those modifcation to what comes from
> the project plugin. Sounds like it would result in relatively complicated
> code.
> 
> Or, maybe store a hash of the targets as they come from the project plugin,
> store the hash together with the override, and only use the override if the
> targets from the project plugin still have the same hash ?
> 
> Something else ?
> 

Like I answered in the previous thread, The feature makes it possible to not 
use sessions and still save build commands. Without this feature I would say 
that the build-plugin becomes a real pain to use if you don't use sessions and 
your project does not give you build commands. And I would say that is so far 
probably 99.9% of all git-based projects...

That said I think it could be considered a bug that an updated project-
configuration does not show up.... That should be handled in some better way. 

The auto-generated targets should probably be read-only.

/Kåre






[prev in list] [next in list] [prev in thread] [next in thread]