cmdfiles

[Ulf Wiger]

On Sat, 29 Jan 2000, Scott Lystig Fritchie wrote:

scott>The Guerrilla 10 Minute Erlang Packaging School
scott>===============================================
scott>
scott>(Constructive criticism is welcome.)

This is a good initiative.


[...]
scott>	1. Create a .app file for each hierarchy in the "ebin" subdir.
scott>	systools:make_script() seems to want the .app file in "ebin"
scott>	instead of "src".  I'd prefer "src", but I haven't figured out
scott>	how.  Perhaps if I look at the Eddie source distribution a bit
scott>	harder....

The .app file *must* be in the "ebin" directory. Sorry.


scott>1. Creating the .app files.
scott>
scott>The two I created are count_server/ebin/count_server.app and
scott>increment/ebin/increment.app.  I don't fully understand all of the
scott>entries, so for those that I also thought were mandatory, I just stuck
scott>something in using "HUH" as a marker that I don't know what I'm doing.
scott>
scott>The count_server/ebin/count_server.app file looks like:
scott>
scott>	{application, count_server,
scott>	 [
scott>	  {description, "Ridiculously brute-force Erlang packaging example"},
scott>	  {vsn, "0.01"},
scott>	  {id, "count_server HUH"},

When building large systems in a large company, all applications may have
to be fitted with a product ID -- for trouble reporting, etc. It is then a
nice feature to be able to call 

  application:get_attribute(count_server, id)

and extract the product id of a certain application in runtime.


scott>	  {modules, [
scott>	             count_server
scott>	            ]
scott>	  },
scott>	  {registered, [ count_server ] },
scott>	  %% NOTE: It seems as if you don't want to list below libraries
scott>	  %% that are load-only.  This is only a list of applications that must
scott>	  %% be started before this application is started.  In the case of
scott>	  %% increment, we'll be starting it ourselves.
scott>	  {applications, [ kernel, stdlib ] },


This is correct, but it shouldn't matter if you list applications that are
load-only (stdlib is such an application). Also, if you're using included
applications (whole other chapter), dependencies are aggregated up to the
top application. This means that you can enter the dependencies where they
actually exist -- you don't have to sum them all up manually at a higher
level.


scott>This lists version dependencies.  If you're using an older Erlang
scott>distribution, you may have to tweak the version numbers for erts,
scott>kernel, and stdlib.  If I recall correctly, make_script will complain,
scott>but it will tell you what versions are installed.  Edit the .rel file,
scott>then try again.

Of course, this can be automated (and has been, in fact, in AXD 301). One
of these days, I'll try to package this as Open Source (but don't hold your
breath.)


scott>Xstart(Type, StartArgs) ->
scott>X    %% Trying to be simple here, so won't use a supervisor tree.
scott>X    case increment:start_link() of
scott>X	{ok, Pid} -> 
scott>X	    {ok, Pid};
scott>X	Error ->
scott>X	    Error
scott>X    end.

The case statement above is redundant. The following behaves exactly the
same:

start(Type, StartArgs) ->
   increment:start_link().


/Uffe