target url from the project manager

[Andreas Pakulat]

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.

Andreas

-- 
You have an unusual understanding of the problems of human relationships.