BINETIX NETWORK

Every MAKE_APP project has to have a text-based configuration file saved in the root directory where the tool-set is going to be used.

The configuration file must be named make_app.config. The name is case sensitive! Detailed explanation about all elements in this file are provided on "Configuration" page.

Now, create a new file named "make_app.config" with your favorite text editor and let's take a look at the sample below.

%%% EXTENSIONS %%%%%%%%%%%%%%%
{include, erlang}.
 
%%% 1. SOLUTION %%%
{solution, my_solution, #{
  name     => "My new AGE App",
  projects => [myapp_2019],
  spec     => [{id, "MY_APP"}, {vsn, "1.0"}, {description, "My new AGE application on Erlang"}]
}}.
 
%%% 2. PROJECTS %%%%%%%%%%%%%%%
{project, myapp_2019, #{
  name   => "My New App Project",
  source => ["src"],
  tasks  => [
    {debug,  [{outdir, "ebin"}, {i, "include"}, {d, '_DEBUG'}]},
    {make,   [local]},
    {run,    [{sname, myapp@localhost}, {setcookie, binetix_age}]}
  ]
}}.
 
%%% 3. TASKS %%%%%%%%%%%%%%%
{task, debug, #{
  label   => "Erlang: DEBUG (compiler)",
  call    => [compile, build],
  command => erlc,
  args    => [
    return_errors,   % Reports compilation errors.
    return_warnings, % Reports compilation warnings.
    debug_info,      % Include debug information in the form of abstract code in the compiled beam module.
    verbose          % Causes more verbose information from the compiler
  ]
}}.
 
{task, make, #{
  label   => "Erlang: Generate boot script",
  call    => [build, deploy],
  command => emake,
  args    => [no_warn_sasl],
  apps    => [
    {kernel, permanent},
    {stdlib, permanent},
    {sasl,   permanent}
  ]
}}.
 
{task, run, #{
  label   => "Erlang: RUN (shell)",
  call    => run,
  command => eshell,
  args    => ["+W w +A 100"]
}}.

The MAKE_APP tool-set has an extremely versatile configuration capabilities:

•The notation used to describe configuration elements is based on standard Erlang terms terminated with a single dot. (DO NOT FORGET THIS DOT)

•The elements can be re-positioned, so the sample above shows just an ordered variant suitable for the this explanation. For example you can put "{include, erlang}." element at the end of the file and the configuration shall be valid.

•The configuration file has to have:

oMany solution elements to describe multiple scopes of different projects and activities.

oMany project elements to describe the scope of each projects of your solution.

oMany task elements to define the custom behavior of your the tasks associated with your projects.

oMany include elements to activate the required extensions to commence the defined tasks.

So, in this particular sample we're going to configure step-by-step an Erlang project.

1)The Erlang extension is activated by element {include, erlang}.;

2)The solution my_solution is described by element {solution, my_solution, <properties>}.,  where project myapp_2019 is selected for processing. The Erlang App resources for this solution are also described in accordance with the standard Erlang/OTP application specifications;

3)The project myapp_2019 is described with element {project, myapp_2019, <properties>}, where the source code in sub-directory "src" shall be processed recursively. The selected tasks to be performed for this project are debug, make and run. These names correspond to the respective task definitions;

4)There are three task definitions described with element {task, <identifier>, <properties>}.

a.Each task can refer to one command provided by some of the activated extensions in the configuration file. In this case the tasks are referring to commands provided by the Erlang extension activated with element {include, erlang}. However,

b.Each task can be invoked from the command line with one or more custom commands specified by the call parameter. For example, in this case both tasks debug and make shall be invoked from the command line with custom command build.

The MAKE_APP tool-set has the syntax from the command line:

$ escript make_app.beam <solution> <call> <options>

where:

o<solution> - The solution identifier specified in the configuration file by the solution element.

o<call> - Custom command for invoking the relevant tasks defined in the configuration file. This parameter is optional. When omitted the MAKE_APP shall perform all tasks from all projects as defined by the configuration.

o<options> - Additional list of properties provided to the invoked commands.

The sample configuration above could be invoked as follows:

1)escript make_app.beam my_solution

This invocation will perform all tasks of solution "my_solution" in the following order: debug — make — run

2)escript make_app.beam my_solution build --all

This invocation will perform only tasks debug — make. Task "debug" will recognize the option -all and will compile all source code files found in sub-directory "src".

The MAKE_APP invocations from the command line could be automated a little bit more by encapsulating some parameters or tasks with OS shell scripts.

Of course, this depends on your particular needs and working habits. Nevertheless, we will offer you two simple scripts for Windows and Linux based on the sample configuration above that could be used as templates in your work.

In these scripts we're assuming that only my_solution shall be processed and you have installed a dedicated OTP 21.1 development environment onto your local file system. The scripts should be invoked from the root directory of your AGE solution.

       make_app.cmd

       make_app.sh