The introduction of setup_env as a global concept caused the rebar_port_compiler
implementation to start getting called a LOT. The expansion of environment variables
that happens in the port compiler was O(n^n), which means you could see upwards of
80k invocations of lists:foldl on a single app "./rebar clean". This commit reworks
the expansion to be O(n^2), and reduces the running time for the same operation by
60%+. On a large project like Riak, the end result is that a build went from 200
seconds to 73.
Currently rebar_utils:sh/2 will invoke all commands through bash.exe if
found. Otherwise the command will be executed directly. Despite the fact
that the caller cannot know if the command is executed with Unix or
Windows semantics it leads to problems with MSYS's automatic path name
translation.
Therefore remove bash usage on Windows to get a consistent behavior and
to avoid the peculiarities of MSYS's automatic path conversion. Instead
use cmd.exe as its typically needed by most commands.
Calling erlang:system_info(wordsize) yields the internal word size of
the Erlang emulator. But due to the halfword emulator, need to pass
{wordsize, external} instead to get the word size, or pointer size, as
seen by external code such as NIFs. The halfword emulator has 4 byte
internal words but 8 byte external words due to 64-bit compilation,
which means NIFs for the halfword emulator also have to be compiled
64-bit. But just passing wordsize is equivalent to passing {wordsize,
internal}, which does not indicate the pointer size for the halfword
emulator.
Older versions of Erlang do not support {wordsize, external}, though,
so continue to pass just wordsize for those versions.
Rebar will exit with {error,bad_directory} when trying to restore the code
path after it has finished working on a subdirectory if there are invalid
relative paths in it. The problem was seen when executing the last line of
rebar_erlc_compiler:doterl_compile/3 (true = code:set_path(CurrPath)).
To further support OTP releases I have added support for generating
application appup files. These include instructions that systools uses
to generate a relup file which contains the low level instructions
needed to perform a hot code upgrade. My goal with this module is to
produce "good enough" appup files or at least a skeleton to help one get
started with something more complex. If an appup file already exists for
an application this command will not attempt to create a new one.
Usage:
$ rebar generate-appups previous_release=/path/to/old/version
Generally this command will be run just before 'generate-upgrade'.
