<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Oct 15, 2008 at 10:24 PM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.de</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 15.10.08 19:20:42, Aleix wrote:<br>
> On Wed, Oct 15, 2008 at 2:33 PM, Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:<br>
</div><div class="Ih2E3d">> > > On Tuesday 14 October 2008 21:50:55 Aleix wrote:<br>
</div><div class="Ih2E3d">> > Or in that case rather ExecutableProjectItem::outputInformation. This<br>
> > latter version imposes added complexity at least for the cmake support,<br>
> > according to Aleix. Its easier for him to have the API on the buildsystem<br>
> > manager.<br>
><br>
><br>
> Well, actually, as I said, now I am storing the information in the item data<br>
> (that's why I said), so it is ok to have it in the item.<br>
> I'm fine with whatever implementation as soon as we have the way to retrieve<br>
> the information.<br>
<br>
</div>Oh, didn't think far enough apparently. Thats quite nice. So I'm voting for<br>
having the item's provide the information. That way we can add it<br>
incrementall, i.e. for now we just provide a builtUrl()+installUrl() method<br>
on Executable and Test target items and once we have the need we can add<br>
the needed methods to library and generic targets.<br>
<div class="Ih2E3d"><br>
> Btw, I still think that the executable url is the executable path itself and<br>
> we don't want the .shell file. We can retrieve the information from the<br>
> .shell file from the buildmanager.<br>
<br>
</div>Actually I agree that we should provide only 1 url for the built and<br>
installed version, however for the built version of cmake projects this<br>
should be the .shell variant. The .shell version allows to run an<br>
executable without having to install the whole project. Granted for KDE<br>
apps thats not quite true, as you still need to have .desktop files,<br>
plugins and so on installed. But it still makes it easier to test a change<br>
in a library.</blockquote><div>the .shell file is kde-and-*nix-dependent AFAIR and it only adds the LD_LIBRARY_PATH and we can get this information... as I said.<br>Why bother to relly on such feature? <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Other buildsystems don't have such a thing, so there we have no choice.<br>
What I'm not sure about is how to choose between the installed and the<br>
in-builddir version of a target. That needs to be inside the run-gui<br>
somehow...</blockquote><div>Well, if the user wants to install, then he will want the installed version i suppose. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Andreas<br>
<font color="#888888"><br>
--<br>
You will contract a rare disease.<br>
</font><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>