Thank you Jim,
That was the problem indeed. Too bad it is not mentioned in the manual.
On Wed, Jun 17, 2020 at 8:33 PM Jim Hester wrote:
>
> I think the issue is likely that you seem to be using a relative path to the
> R_MAKEVARS_USER file, it needs to be an absolute path as the installation is
I think the issue is likely that you seem to be using a relative path to
the R_MAKEVARS_USER file, it needs to be an absolute path as the
installation is run in a temporary directory not from the directory you
call `R CMD INSTALL` from.
I observed similar behavior to what you describe when I had th
What is the problem exactly? variable name is hardcoded, and variable
value is hardcoded as well.
How it is possible for the second `system` call to deliver different
makevars file than the first one?
This is the problem in question.
Yes, I haven't thought about Windows. I should have mentioned I
Each call to system is independent, so it definitely is a problem.
Use Sys.setenv to make changes in environment variables that can be used within
system calls.
Bash is not involved with the system call on Windows... so your syntax for
setting an environment variable is not portable.
On June 1
Thank you Jeff for your comments.
Yet they does not seem to be related.
a) Environment variable is created inside `system` command, so env var
stays valid for the command. Which is confirmed in the first call that
properly shows CFLAGS.
b) Syntax passed checkbashisms so I expect no problems due to
I don't know anything about the function of that environment variable, but
a) system() invokes a child process so environment variable changes made using
it will only affect the child process created by that system call.
b) The syntax you have used is shell-specific, so does not look portable.
Hi package devel support,
I am trying to use R_MAKEVARS_USER to customize build, rather than
.R/Makevars. It is properly displayed from config CFLAGS but during
package install it doesn't seem to work.
In R-admin in "6.3.3 Customizing package compilation" there is:
> Note that these mechanisms d