| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
reltool is missing an app resource file before R14A.
Therefore, restore the old check and add TODO.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If running e.g. rebar generate using an OTP development build,
rebar will complain that reltool has the version "", which is
less than the required "0.5.2". This is because rebar_reltool
simply checks the path returned by code:which(reltool), which
doesn't yield version information if used in a development build.
This patch substitutes a more robust method (load reltool and
fetch the info from application:loaded_applications()).
As it happens, this will not be enough to make things work,
but now Reltool will explain that it cannot generate a spec
from a system that is not installed, giving a better hint
as to what needs to be done.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating a node using rebar generate, rebar always used
code:root_dir() to find the Erlang installation to clone into the node
tree. However, for anyone wishing to build a cross-compiled node, there
was no way to override this. This patch adds a new option to
reltool.config file to allow an alternate root_dir to be specified, for
example:
{root_dir, "/tmp/otp_R14B03_armv7l"}
This assumes that the contents of /tmp/otp_R14B03_armv7l has been
generated using the instructions found in the xcomp directory in your
$ERL_TOP structure. NOTE: you may have to add additional filters to
exclude files not present in the xcomp version, such as the .smp files
if you have disabled that.
|
|
|
|
|
|
|
|
| |
required for building on a different machine to what your live
config is kept on. This way you can build on one machine,
distribute to new machine, then run overlays against a live
config to prevent accidently running code against a live
config in a development or ci environment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
app.config has been a long standing erroneous file in rebar. Erlang/OTP
documentation suggests a sys.config file instead. This file is stored in
the releases/VSN directory. This does a few things but most importantly
it ensures your config (contained in the application environment)
survives a hot upgrade. It also has the advantage of allowing the
configuration of the application to be versioned along side the
application code. This patch flips rebar to use sys.config rather than
app.config.
Additionally it makes this flip to vm.args as well, making them
versioned just like sys.config.
This patch also includes runner script changes to support the old
etc/app.config config file location and support for Windows.
Thanks to mokele for the initial work and kick in the pants to make this
finially happen.
|
|
|
|
|
|
|
|
|
|
|
| |
The target_dir config in reltool allows you to put your release in
a directory other than in ./NAME, so we should look in the parent
directory of that to find the new and old versions instead of
simply looking in ./
Move untaring and retaring into a temporary path instead of in ./
to prevent name collisions with "releases" and "lib" that might
exist already. Having a subdirectory rel/releases/ can be useful.
|
| |
|
| |
|
| |
|
|
|
|
| |
be templated.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Modify rm_rf and cp_r to work when {win32,_} = os:type().
Simplify rm_rf to only accept one filename, directoryname or wildcard.
Add unit tests to ensure a similar behaviour on windows and unix.
Thanks to tuncer for guidance and feedback.
|
| |
|
| |
|
|
|
|
| |
work (excepting reltool support) with anything as far back as R12, once you've compiled it
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
templating overlay files
--HG--
extra : rebase_source : f042bd65d63dbaf4177f444f66033883bf7522a5
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
overwritten by canonical install
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
missing apps in code path
|
|
|