Jim Walker wrote:
> Raymond Xiong wrote:
>> When I used the following way to test my packaging code for
>> Erlang, I hit an unexpected issue.
>>
>> $ env - <path_to_nightly> <env_file>
>>
>> Erlang source code contains .c files and .erl files. .c files
>> are mainly used to compile VM and utilities, which then are
>> used to compile .erl files.
>>
>> Unfortunately those utilities(Erlang runtime actually) requires
>> HOME directory, but that is unset by "env -"
>>
>> I am trying to solve this issue by defining "HOME=/tmp" in
>> Erlang subdir's Makefile.sfw. But since this is a general
>> issue caused by "env -" usage, I wonder if anyone has better
>> suggestion for this? I think we should support "env -" usage,
>> right?
>>
>
> You should be able to add any variable to your "new" environment
> by doing something like this:
>
> % env - HOME=<path_to_home> <path_to_nightly> <env_file> &
>
> For example:
>
> % env - HOME=/export/home/xyz /opt/onbld/bin/nightly sfw-developer.sh &
>
though I'd wonder what it is doing in HOME before I chose what to
set it to. If it just needs it set to something, it doesn't matter.
But if it's going to be scribbling around in $HOME/.somefilename then
you shouldn't set HOME to something common like /tmp or multiple builds
on the same machine might fail interestingly if they collide in erlang.
In that case I'd probably set it to something in your build area
(like if you're building erlang, $SRC/cmd/erlang/tmp or whatever) and
I might even do it in each Makefile.sfw instead so that it's the
same for each person who builds it and it doesn't leave things in
folks home directories.
Mike
