target url from the project manager
Andreas Pakulat
apaku at gmx.de
Thu Oct 16 22:54:05 UTC 2008
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
--
Try to have as good a life as you can under the circumstances.
More information about the KDevelop-devel
mailing list