adding and removing items from a buildtool

[Aleix]

On Wed, Nov 12, 2008 at 1:01 PM, Andreas Pakulat <apaku at gmx.de> wrote:

> On 12.11.08 11:49:32, Aleix wrote:
> > On Wed, Nov 12, 2008 at 5:55 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> >
> > > On 12.11.08 02:57:12, Aleix wrote:
> > > > hi!
> > > > I was taking a look at the API we have right now to add and remove
> items
> > > > from a buildtool (IProjectFileManager + IBuildSystemManager), here
> there
> > > are
> > > > some thoughts:
> > > > - We can either add files to a target or to a folder, sounds
> confusing
> > > (even
> > > > if i understand the reason).
> > >
> > > Not really, IMHO. Adding a file to a folder means putting that file
> > > somewhere into the project tree, whatever type of file. Adding a file
> to a
> > > target means: "I want this target to use the code from this file".
> > >
> > > >    -> Why don't he overload to add to a folder or a target depending
> on
> > > the
> > > > parent type?
> > >
> > > You mean renaming the addFileToTarget function in the
> buildsystemmanager?
> > > I'm split here between consistent API (i.e. renaming it) and clear API
> that
> > > tells you what it'll do. I guess with good code-completion its easy
> enough
> > > to see that the parameters have different types. I don't want to see
> the
> > > the method being called with a ProjectBaseItem because thats not
> verbose
> > > enough on which types are allowed and which are not.
> >
> > Well, we only can add it to a Directory and to a Target, 2 cases, not 1
> > baseitem.
>
> Yeah, as I said I'm undecided of having the same method name with different
> parameters, i.e. having
>
> addFile( const KUrl& file, ProjectFolderItem* item);
>
> in IProjectFileManager and
>
> addFile( ProjectFileItem*, ProjectTargetItem* );
>
> in IBuildSystemManager. I simply don't know if this might be confusing or
> not.

Project items are created by the projectmanager now, do you want to change
that?


>
>
> > > > - If we can rename a file we should provide it its new parent, not
> just
> > > the
> > > > Url, same for directory.
> > >
> > > Why? If you not just rename, but also move the file, you can find the
> right
> > > parent folder easily by using the new-url. You can't move around a file
> > > from one target to another this way, in fact I think existing targets
> using
> > > the old file need to automatically be changed to use the new filename.
> > >
> > Then why do we need the parent when adding a file? We could just figure
> out
> > too.
>
> Indeed. With our current project tree there's no reason why you'd have a
> folder with items in it that point into another folder. Except maybe, if
> those files are outside the projects source dir. Hmm, so we could probably
> have the ProjectFolderItem default to 0 and inside the addFile
> implementation use it only if its != 0 and the file is inside the projects
> sourcedir.
>
> > > So, I'm not sure we should let the user edit the file when add/remove
> was
> > > called in the API. A simple preview-widget that shows the area thats
> going
> > > to be changed could be enough, if the user wants to do something more
> > > complex, he can just cancel this and write the CMakeLists.txt file
> > > manually.
> >
> > That's the other option I had in mind... Do you think it is better?
>
> Yes I think so. If we allow the user to edit the CMake-file for adding a
> .cpp to the project, he can also do other things we don't know about. Which
> means we'd have to reparse the file, which means we can't possibly know
> wether the file was added or not, so we can't emit the signal.

Maybe we have to track states when reloading because if the user wants to
change it manually we will want to get these signals then... isn't it? :S or
maybe we just want to track the model changes...


>
> Andreas
>
> --
> Learn to pause -- or nothing worthwhile can catch up to you.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20081112/1d478ade/attachment.html>