target url from the project manager

Andreas Pakulat apaku at gmx.de
Wed Oct 15 12:29:17 UTC 2008


On 15.10.08 04:36:02, Aleix wrote:
> 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?

The problem we had was that ideally this would be methods on the individual
target items. However you said that this would make things for cmake overly
complex and it would be easier to have a function in the buildsystem
manager that provides the url(s) for a given target.

We tried to come up with reasonable API's in cases like library targets,
which can provide multiple output files. The same is true, btw, for
unit-tests (which have an executable and a shell script - at least on
unix).

The question I have right now: Do we expect/can someone come up with
use-cases where the caller of
IBuildSystemManager::targetOutputInformation() doesn't know or care about
the actual target type? If the answer to that is "no", we can simply use
QVariant as return type and then provide all of the above, depending on our
input type. If the answer is "yes", then we've got find a way to make this
work with a single return type - maybe a new class that has a getBuiltUrl()
and getInstalledUrl() with a type-argument...

Andreas

-- 
You have many friends and very few living enemies.




More information about the KDevelop-devel mailing list