Hi there,
One of the macros we have in KDE creates shell scripts to initialize
environment variables needed on various platforms so that tests can be run
before installation. If RPATH is enabled, the scripts are not needed, but
RPATH is sometimes disabled, so the scripts are the solution to th
On Friday 17 February 2012, Stephen Kelly wrote:
> Hi there,
>
> One of the macros we have in KDE creates shell scripts to initialize
> environment variables needed on various platforms so that tests can be run
> before installation. If RPATH is enabled, the scripts are not needed, but
> RPATH is
Hi,
On Fri, 2012-02-17 at 08:51 +0100, Alexander Neundorf wrote:
-- 8< 8< 8< 8< 8< 8< 8< 8< 8< --
> > So the suggestion is
> >
> > a) Change CMAKE_SKIP_RPATH to only skip RPATH when installing, but
not when
> > building (I don't know if that's easy in CMa
2012/2/17 Alexander Neundorf :
>
> a) To change CMAKE_SKIP_RPATH so that it leaves the RPATH on in the build
> tree, but not in the install tree, IMO makes sense.
We already have
CMAKE_SKIP_RPATH
CMAKE_SKIP_BUILD_RPATH
may be we are missing
CMAKE_SKIP_INSTALL_RPATH
or that
CMAKE_SKIP_RPATH set t
Marcel Loose wrote:
> Hi,
>
> On Fri, 2012-02-17 at 08:51 +0100, Alexander Neundorf wrote:
>
> -- 8< 8< 8< 8< 8< 8< 8< 8< 8< --
>
>> > So the suggestion is
>> >
>> > a) Change CMAKE_SKIP_RPATH to only skip RPATH when installing, but
> not when
>> > build
Hi Stephen,
On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
-- 8< 8< 8< 8< 8< 8< 8< 8< 8< --
> diff --git a/templates/tests/CMakeLists.txt
b/templates/tests/CMakeLists.txt
> index d2e37d2..ad471c7 100644
> --- a/templates/tests/CMakeLists.txt
> +++
Marcel Loose wrote:
> Hi Stephen,
>
> On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
>
> -- 8< 8< 8< 8< 8< 8< 8< 8< 8< --
>
>> diff --git a/templates/tests/CMakeLists.txt
> b/templates/tests/CMakeLists.txt
>> index d2e37d2..ad471c7 100644
>> ---
2012/2/17 Stephen Kelly :
> Marcel Loose wrote:
>
>> Hi Stephen,
>>
>> On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
>>
>> -- 8< 8< 8< 8< 8< 8< 8< 8< 8< --
>>
>>> diff --git a/templates/tests/CMakeLists.txt
>> b/templates/tests/CMakeLists.txt
>>> in
Eric Noulard wrote:
> 2012/2/17 Stephen Kelly
> :
>> Marcel Loose wrote:
>>
>>> Hi Stephen,
>>>
>>> On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
>>>
>>> -- 8< 8< 8< 8< 8< 8< 8< 8< 8< --
>>>
diff --git a/templates/tests/CMakeLists.txt
>>> b/te
On Friday 17 February 2012, Stephen Kelly wrote:
...
> The other issue is regarding setting RPATH for the build step and not the
> install step, and what syntax should be used for that.
>
> The options are:
>
> a) Change the behaviour of CMAKE_SKIP_RPATH to set the RPATH in the build
>dir (do
Alexander Neundorf wrote:
> On Friday 17 February 2012, Stephen Kelly wrote:
> ...
>> The other issue is regarding setting RPATH for the build step and not the
>> install step, and what syntax should be used for that.
>>
>> The options are:
>>
>> a) Change the behaviour of CMAKE_SKIP_RPATH to se
On 2/17/2012 9:13 AM, Stephen Kelly wrote:
If CMAKE_SKIP_INSTALL_RPATH is used by our buildsystems and CMAKE_SKIP_RPATH
is not, distros will learn that they can run unit tests if they build their
packages with the former instead of the latter.
From my point of view though, the ENVIRONMENT prope
On Friday 17 February 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Friday 17 February 2012, Stephen Kelly wrote:
> > ...
> >
> >> The other issue is regarding setting RPATH for the build step and not
> >> the install step, and what syntax should be used for that.
> >>
> >> The op
On 2/17/2012 9:31 AM, Alexander Neundorf wrote:
Yes, but this could be done already right now.
We (KDE) could add an option(), which when enabled sets CMAKE_INSTALL_RPATH
empty, and CMAKE_INSTALL_RPATH_USE_LINK_PATH to FALSE. This would be the same
effect.
CMAKE_SKIP_RPATH is intentionally for p
Brad King wrote:
> On 2/17/2012 9:13 AM, Stephen Kelly wrote:
>> If CMAKE_SKIP_INSTALL_RPATH is used by our buildsystems and
>> CMAKE_SKIP_RPATH is not, distros will learn that they can run unit tests
>> if they build their packages with the former instead of the latter.
>>
>> From my point of vi
On 2/19/2012 6:38 PM, Stephen Kelly wrote:
I have also added a skip-install-rpath branch to my clone for review.
So far it's a quick hack. I'm not sure if I'm barking up the right or wrong
tree.
That's a good start. However I do not think the logic plays well
with BUILD_WITH_INSTALL_RPATH as
Brad King wrote:
> On 2/19/2012 6:38 PM, Stephen Kelly wrote:
>> I have also added a skip-install-rpath branch to my clone for review.
>>
>> So far it's a quick hack. I'm not sure if I'm barking up the right or
>> wrong tree.
>
> That's a good start. However I do not think the logic plays well
>
Brad King writes:
> That's a good start. However I do not think the logic plays well
> with BUILD_WITH_INSTALL_RPATH as currently written. If that is
> set then the build tree should end up with the install-tree rpath
> which should be empty if SKIP_INSTALL_RPATH is on. Therefore
> the relink/
On Sun, Mar 4, 2012 at 5:18 PM, Stephen Kelly wrote:
>> That's a good start. However I do not think the logic plays well
>> with BUILD_WITH_INSTALL_RPATH as currently written. If that is
>> set then the build tree should end up with the install-tree rpath
>> which should be empty if SKIP_INSTALL
Brad King wrote:
> On Sun, Mar 4, 2012 at 5:18 PM, Stephen Kelly
> wrote:
>>> That's a good start. However I do not think the logic plays well
>>> with BUILD_WITH_INSTALL_RPATH as currently written. If that is
>>> set then the build tree should end up with the install-tree rpath
>>> which shoul
On 3/5/2012 10:47 AM, Stephen Kelly wrote:
e1b4fec8dd73cc675b3a20f2e045c6282c47553a in my gitorious clone contains the
updated state. It behaved as I expected in all combinations I tested.
Much cleaner, thanks. Here are some more comments.
> outputRuntime && linking_for_install &&
> -
Brad King wrote:
> Much cleaner, thanks. Here are some more comments.
Thanks, I'll try to clean up the remaining messiness later when I can give
it my full attention. With the remaining goobers, clearly I'm not giving it
enough at the moment :).
Thanks,
Steve.
--
Powered by www.kitware.co
Stephen Kelly wrote:
> Brad King wrote:
>
>> Much cleaner, thanks. Here are some more comments.
>
> Thanks, I'll try to clean up the remaining messiness later when I can give
> it my full attention. With the remaining goobers, clearly I'm not giving
> it enough at the moment :).
I updated the
On 3/5/2012 4:26 PM, Stephen Kelly wrote:
I updated the branch again. It is now
635bf50c27aef184bfa1698953dd44361e1fb2f9
Great, thanks. Please merge to 'next' for testing.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/open
Brad King wrote:
> On 3/5/2012 4:26 PM, Stephen Kelly wrote:
>> I updated the branch again. It is now
>> 635bf50c27aef184bfa1698953dd44361e1fb2f9
>
> Great, thanks. Please merge to 'next' for testing.
>
Done. Thanks for the review.
Steve.
--
Powered by www.kitware.com
Visit other Kitware
25 matches
Mail list logo
