<div dir="ltr">Well, I'm fine with exposing targets as executable only and adding the tests somewhere else, just tell me where do you want that.<br><br>I agree the interface we have now is not nice enough.<br><br>bye,<br>
Aleix<br><br><div class="gmail_quote">On Thu, Oct 16, 2008 at 12:08 PM, M Breugelmans <span dir="ltr"><<a href="mailto:mbr.nxi@gmail.com">mbr.nxi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Thu, Oct 16, 2008 at 11:38 AM, Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:<br>
> On 16.10.08 11:12:47, M Breugelmans wrote:<br>
>> On Wed, Oct 15, 2008 at 4:36 AM, Aleix <<a href="mailto:aleixpol@gmail.com">aleixpol@gmail.com</a>> wrote:<br>
>> > Maybe we can add it only to test and executable target items<br>
>><br>
>> Test-target items are a KDE only thing (as discussed a little on this<br>
>> list before). That should be removed from the api, at least if<br>
>> kdevelop aims to support cmake instead of kde-cmake :)<br>
>><br>
>> enable_testing()<br>
>> add_executable(foo foo.cpp)<br>
>> add_test(foo echo "test 123")<br>
><br>
> Hmm, I thought the test-foo would still create a real target.<br>
><br>
>> 'echo "test 123"' is not a url ... Maybe this info should not be in<br>
>> the IBuildSystemManager nor project model at all, but only available<br>
>> through CMakeManager. Sure downcasting/RTTI is considered bad but<br>
>> polluting these interfaces with cmake+ctest specific stuff is worse.<br>
>> If, at some point, there's another build system implemented that<br>
>> provides similar info then it could be moved to a general interface.<br>
><br>
> There's two things I don't like much with your idea:<br>
><br>
> a) we can't change interfaces once they're released without breaking BiC<br>
<br>
</div>I'm not familiar with BiC problems but doesn't that only apply in<br>
between major releases? If that's the case it's not that much of a<br>
problem with a 6-month release cycle.<br>
<div class="Ih2E3d"><br>
> b) cmake would need to provide an interface to the manager and it would<br>
> need to provide a way of retrieving tests and finding the "executable" for<br>
> a test<br>
><br>
> Which leads me to think: Why is this not part of the platform? Why don't we<br>
> have something like ITestSystemManager or so, which allows to retrieve the<br>
> tests inside a project, allows to add new ones and so on.<br>
<br>
</div>That would duplicate functionality with veritas, which already keeps<br>
track of test exes. I have a partial redesign in mind that makes a<br>
TestExecutable more of a prime citizen though.<br>
<div class="Ih2E3d"><br>
> That is if we really don't want them as targets inside the project tree,<br>
> which I still think might make sense even if not in all cases (like the<br>
> above). I mean having an executable for a test is not necessarily a kde<br>
> thing, one would probably do that in other cases as well. So a test-target<br>
> would always have something that is executable<br>
<br>
</div>Target here (I think) means build-target, which it isn't. The cmake<br>
add_test command does not add a make target, so KDevelop should not<br>
try to do that either. Often you will have test scripts which need not<br>
be build at all.<br>
<div class="Ih2E3d"><br>
> (the echo above is too), but<br>
> it doesn't have to be a plain url. It might as well be a list of strings<br>
> which are to be used for a process-run (arg0..argn). And internally we'll<br>
> want to link a kde4 unit test target with its executable - not sure how to<br>
> best do that inside the GUI though (as showing both would be strange).<br>
><br>
<br>
</div>If you are talking about the project-toolview: imo test information<br>
should not be shown there. That's again duplication :)<br>
<br>
<br>
Manuel<br>
<div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br></div>