Buildtool: Getting the url from any target
aleixpol at gmail.com
Sat Jun 21 11:46:12 UTC 2008
Ok, maybe the problem is to get the URL for libraries. Afterall the ones
that we might want at some point is only executables. If we need libraries
at some point we can extend it to return many urls or whatever.
On Sat, Jun 21, 2008 at 12:33 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> 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,
> > 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
> > 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
> > 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:
> - TestExecutableTargetItem
> 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.
> Time to be aggressive. Go after a tattooed Virgo.
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KDevelop-devel