Buildtool: Getting the url from any target

Andreas Pakulat apaku at gmx.de
Sat Jun 21 10:33:50 UTC 2008


On 20.06.08 22:25:17, Aleix wrote:
> in a previous message we spoke about making a difference for the test
> targets so that we had a way to get a test and its url.
> 
> Going forward with the idea, I thought that maybe it would be nice to be
> able to get the url from any target. Afterall it would be the same work, so
> it would be nice.

And as Manuel already said, eventually having special subclasses for
some/all target types (testtarget, library target, ...)

> I have been speaking about this with apaku in the IRC and we didn't get to
> have a good API for it so we decided to discuss it here with calm and
> harmony. :) The main problem is that, as apaku said, in some platforms a
> target can have more than 1 url. I don't really see the problem, but I'll
> let him to make it clear :P.

The problem is mainly win32 I think (dunno much about OSX, but I know no
other *nix that has the following). There a shared library has _at
least_ two files: .dll and .lib or .dll.a (depending on compiler). The
latter has all the exported symbols for the .dll and is needed to link
against the .dll. Then there's often also an extra library for debug
symbols (IIRC) and eventually a manifest file. If we provide something
like:

> My initial idea was something like:
> KUrl IBuildSystemManager::targetUrl(ProjectTargetItem*) const

We need a way to get these extra files as well, IMHO. If we assume that
we split targetitem into multiple subclasses:

ExecutableTargetItem
|
- TestExecutableTargetItem

LibraryTargetItem

CustomTargetItem

Then we can just provide a targetUrl() method on those, and for
LibraryTargetItem we can provide something like targetUrl( FileType );
(where FileType would be Library, Import, Debug, Manifest). And of
course defaults to Library.

The problem with just having IBuildSystemManager::url() is that people
who need the import lib or something else are forced to do
someurl.toString().replace(".dll",".lib") and then also check the
compiler as ming actually created .dll.a for import libs.

Andreas

-- 
Time to be aggressive.  Go after a tattooed Virgo.




More information about the KDevelop-devel mailing list