Native Windows support
dizzyd at basho.com
Tue Jan 11 09:21:43 EST 2011
On Sat, Jan 8, 2011 at 7:57 PM, Kyle Quest <kcq.lists at gmail.com> wrote:
> When rebar combines all variables from the OS environment, default
> build variables, and user provided port environment variables it also
> goes through all of them and "expands" $VARNAME in the environment
> variable collection. There's a chance that rebar will substitute
> something it shouldn't because some of the OS environment variables
> (configured by other applications) happen to have $VARNAME in their
> values, which, on Windows, isn't even an environment variable (on
> Windows an env variable is looks like this: %VARNAME%). I had to fight
> with this a couple of times and it caused my builds to break on one
> machine while it worked on another.
This just sounds like we need to make the expansion honor Windows
%VARNAME% and, optionally, ignore $VARNAME in that circumstance.
> This leads to the main problem with the environment variables:
> variable collision. This problem becomes even worse these days on
> Windows because of Cygwin and a lot of tools that use a lot of unix
> tools behind the scene (which, as you'd expect, depend on the same
> environment variables).
Can you elaborate on the specific variables which are colliding and
the circumstances, please?
> Another problem is the difference in the OS shell behavior and MS
> compiler invocations... On unix shells you can invoke a compiler with:
> $CC $CFLAGS etc
> On Windows that simply doesn't work...
We could (easily, I think) take expansion a step further and expand
the command line before invoking it.
More information about the rebar