target url from the project manager

[Aleix]

On Wed, Oct 15, 2008 at 2:33 PM, Andreas Pakulat <apaku at gmx.de> wrote:

> On 14.10.08 22:07:42, Matt Rogers wrote:
> > On Tuesday 14 October 2008 21:50:55 Aleix wrote:
> > > On Wed, Oct 15, 2008 at 4:42 AM, Matt Rogers <mattr at kde.org> wrote:
> > > > On Tuesday 14 October 2008 21:36:02 Aleix wrote:
> > > > > hi list,
> > > > > this was discussed some time ago but we didn't find anything good
> but
> > > > > we didn't come up with a good interface for that. Now it is needed
> for
> > > > > the
> > > >
> > > > new
> > > >
> > > > > runcontroller, we want to be able to run any target.
> > > > >
> > > > > This is being solved in cmake adding the url to the UserData+1 (it
> is
> > > > > already possible to run a target from the projectmodelview if it is
> > > >
> > > > cmake),
> > > >
> > > > > we need a way to specify it in the platform interface.
> > > > >
> > > > > Last time we spoke about many things, returning: KUrl, KUrl::List,
> > > > > QMap<QString, KUrl> iirc. What do you think?
> > > > > Maybe we can add it only to test and executable target items so
> that
> > > > > the use case is simpler, I think that KUrl::List would be quite
> > > > > scalable for now. What do you think?
> > > > >
> > > > > bye!
> > > > > aleix
> > > >
> > > > What would the KUrl::List be used for? A list of all the executable
> URLs?
> > >
> > > Well, the problem is that 1 target might generate more than 1 file ->
> more
> > > than 1 url. The example that apaku used was that a library in windows
> is
> > > composed by many files.
> >
> > Yeah, but you can't run a library, can you?
>
> Right, the problem is if we put this API on IBuildSystemManager it better
> also work for all other types of targets as we can't change that interface
> easily. Also what about custom targets, which also might have multiple
> output files (which is what this API gives access to basically)
>
> > I think we should limit this particular piece of information only to the
> > executable targets. KUrl::List then becomes a good candidate for storing
> > that information.
>
> Actually just KUrl, because we're talking about accessing the information
> for one specific target.
>
> See my other post for more information.
>
> > But then again, perhaps I miss something and this is about more than just
> > being able to have a list of executable targets per project.
>
> The use-case that Aleix has right now is exactly that, but we didn't like
> the idea of having
>
> IBuildSystemManager::executableTargetOutput( ExecutableProjectItem* )
> IBuildSystemManager::libraryTargetOutput( LibraryProjectItem* )
>
> Or in that case rather ExecutableProjectItem::outputInformation. This
> latter version imposes added complexity at least for the cmake support,
> according to Aleix. Its easier for him to have the API on the buildsystem
> manager.


Well, actually, as I said, now I am storing the information in the item data
(that's why I said), so it is ok to have it in the item.
I'm fine with whatever implementation as soon as we have the way to retrieve
the information.

Btw, I still think that the executable url is the executable path itself and
we don't want the .shell file. We can retrieve the information from the
.shell file from the buildmanager.


>
> Andreas
>
> --
> You have an unusual understanding of the problems of human relationships.
>
> _______________________________________________
> 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/20081015/a0ac4e39/attachment.html>