target url from the project manager

[Matt Rogers]

On Thursday 16 October 2008 17:54:05 Andreas Pakulat wrote:
> On 16.10.08 16:48:05, Matt Rogers wrote:
> > On Thursday 16 October 2008 05:08:33 M Breugelmans wrote:
> > > On Thu, Oct 16, 2008 at 11:38 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> > > > On 16.10.08 11:12:47, M Breugelmans wrote:
> > > >> On Wed, Oct 15, 2008 at 4:36 AM, Aleix <aleixpol at gmail.com> wrote:
> > > >> > Maybe we can add it only to test and executable target items
> > > >>
> > > >> Test-target items are a KDE only thing (as discussed a little on
> > > >> this list before). That should be removed from the api, at least if
> > > >> kdevelop aims to support cmake instead of kde-cmake :)
> > > >>
> > > >> enable_testing()
> > > >> add_executable(foo foo.cpp)
> > > >> add_test(foo echo "test 123")
> > > >
> > > > Hmm, I thought the test-foo would still create a real target.
> > > >
> > > >> 'echo "test 123"' is not a url ... Maybe this info should not be in
> > > >> the IBuildSystemManager nor project model at all, but only available
> > > >> through CMakeManager. Sure downcasting/RTTI is considered bad but
> > > >> polluting these interfaces with cmake+ctest specific stuff is worse.
> > > >> If, at some point, there's another build system implemented that
> > > >> provides similar info then it could be moved to a general interface.
> > > >
> > > > There's two things I don't like much with your idea:
> > > >
> > > > a) we can't change interfaces once they're released without breaking
> > > > BiC
> > >
> > > I'm not familiar with BiC problems but doesn't that only apply in
> > > between major releases? If that's the case it's not that much of a
> > > problem with a 6-month release cycle.
> >
> > No, it applies for series numbers. So we can't break BC again until
> > KDevelop 5.
>
> Thats actually a bit over-simplifying matters. trunk/kdevelop doesn't have
> any notion of BiC because its just an executable+plugins. None of them need
> to keep BC. trunk/kdevplatform on the other hand consists of public API in
> libraries, which means you can't break BC in any 1.x release. However so
> far we're not promising that the second release of kdevplatform will be
> 1.1, it might be 2.0 - because we find that we need to break BC. I'm pretty
> sure the third public feature release will be 2.1, else we're doing
> something wrong :)
>
> Andreas

yes, i oversimplified it. Thanks for clarifying it.
-- 
Matt