Just to put closure to this: Thanks to a few more off-list messages with
Simon who suggested a nice a improvement on the prior setup based on using an
environment variable, plus testing by Valentin, this issue is now taken care
of in SVN.
Thanks to everybody who helped making Rcpp that little bit
On Apr 27, 2013, at 8:47 PM, Valentin Kuznetsov wrote:
> Hi Dirk,
> environment variable is not that bad and I'm ok with such solution.
I'd say something along the lines of
: ${INSTALL_NAME_TOOL=/usr/bin/install_name_tool}
should be clear enough ...
Cheers,
S
> Valentin.
>
> On Apr 27, 20
On 27 April 2013 at 20:47, Valentin Kuznetsov wrote:
| Hi Dirk,
| environment variable is not that bad and I'm ok with such solution.
A simple snippet should do. First attempt (indented two for the email)
# -*- mode: makefile -*-
all: setval
echo The value is ${val}
setval:
if
Hi Dirk,
environment variable is not that bad and I'm ok with such solution.
Valentin.
On Apr 27, 2013, at ,Apr 27, 9:52 AM, Dirk Eddelbuettel wrote:
>
> On 26 April 2013 at 20:11, Valentin Kuznetsov wrote:
> | Simon,
> |
> | >
> | > I suppose it would be possible to replace it simply with
> |
On 26 April 2013 at 20:11, Valentin Kuznetsov wrote:
| Simon,
|
| >
| > I suppose it would be possible to replace it simply with
| > @-install_name_tool -id $(R_PACKAGE_DIR)/lib$(R_ARCH)/$(USERLIB)
$(USERLIB) 2>/dev/null
|
| I'll leave it up to you (or to developers) to decide. In any case
On 26 April 2013 at 19:12, Simon Urbanek wrote:
| On Apr 26, 2013, at 6:38 PM, Valentin Kuznetsov wrote:
|
| > Dirk,
| >
| > having hard-coded path is usually lead to trouble regardless of the OS.
Users may have dedicated system with specific compiler/tools in different
location. What you need
Simon,
>
> I suppose it would be possible to replace it simply with
> @-install_name_tool -id $(R_PACKAGE_DIR)/lib$(R_ARCH)/$(USERLIB)
> $(USERLIB) 2>/dev/null
I'll leave it up to you (or to developers) to decide. In any case it would be
appropriate to document this use case and provide
On Apr 26, 2013, at 6:38 PM, Valentin Kuznetsov wrote:
> Dirk,
>
> having hard-coded path is usually lead to trouble regardless of the OS. Users
> may have dedicated system with specific compiler/tools in different location.
> What you need is auto-detection of required components. Since /usr/b
Dirk,
having hard-coded path is usually lead to trouble regardless of the OS. Users
may have dedicated system with specific compiler/tools in different location.
What you need is auto-detection of required components. Since /usr/bin is
always in a PATH you don't really need it either. But as I
Hi Valentin,
Thanks for subscribing.
On 26 April 2013 at 17:08, Valentin Kuznetsov wrote:
| Hi,
| this is re-post from
|
https://r-forge.r-project.org/tracker/?func=detail&atid=637&aid=2743&group_id=155
| as been advised by Dirk.
Now that you are here, let me repost what I wrote earlier. I'll
10 matches
Mail list logo