target url from the project manager

[M Breugelmans]

On Wed, Oct 15, 2008 at 10:43 PM, Aleix <aleixpol at gmail.com> wrote:
>
>
> On Wed, Oct 15, 2008 at 10:24 PM, Andreas Pakulat <apaku at gmx.de> wrote:
>>
>> On 15.10.08 19:20:42, Aleix wrote:
>> > On Wed, Oct 15, 2008 at 2:33 PM, Andreas Pakulat <apaku at gmx.de> wrote:
>> > > > On Tuesday 14 October 2008 21:50:55 Aleix wrote:
>> > > Or in that case rather ExecutableProjectItem::outputInformation. This
>> > > latter version imposes added complexity at least for the cmake
>> > > support,
>> > > according to Aleix. Its easier for him to have the API on the
>> > > buildsystem
>> > > manager.
>> >
>> >
>> > Well, actually, as I said, now I am storing the information in the item
>> > data
>> > (that's why I said), so it is ok to have it in the item.
>> > I'm fine with whatever implementation as soon as we have the way to
>> > retrieve
>> > the information.
>>
>> Oh, didn't think far enough apparently. Thats quite nice. So I'm voting
>> for
>> having the item's provide the information. That way we can add it
>> incrementall, i.e. for now we just provide a builtUrl()+installUrl()
>> method
>> on Executable and Test target items and once we have the need we can add
>> the needed methods to library and generic targets.
>>
>> > Btw, I still think that the executable url is the executable path itself
>> > and
>> > we don't want the .shell file. We can retrieve the information from the
>> > .shell file from the buildmanager.
>>
>> Actually I agree that we should provide only 1 url for the built and
>> installed version, however for the built version of cmake projects this
>> should be the .shell variant. The .shell version allows to run an
>> executable without having to install the whole project. Granted for KDE
>> apps thats not quite true, as you still need to have .desktop files,
>> plugins and so on installed. But it still makes it easier to test a change
>> in a library.
>
> 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.
> Why bother to relly on such feature?

I don't think .shell should be in the interface either, due to being
kde4 specific. I have actually switched to using LD_LIBRARY_PATH for
the cmake/ctest thing a couple of weeks ago.

>>
>> Other buildsystems don't have such a thing, so there we have no choice.
>> What I'm not sure about is how to choose between the installed and the
>> in-builddir version of a target. That needs to be inside the run-gui
>> somehow...
>
> Well, if the user wants to install, then he will want the installed version
> i suppose.
>>

Maybe this is something the user has to decide for him/herself? It's a
simple matter of adding the lib path to LD_LIBRARY_PATH or not anyway
... at least for cmake+unix


Manuel