Compiling .rel-files - module search path

Ulf Wiger <>
Mon Aug 29 22:36:43 CEST 2005


Den 2005-08-29 15:51:35 skrev Gunilla Arendt <>:

> erlc for a .rel file calls systools:make_script/2 to generate the boot  
> script. For every application, systools:make_script/2 looks for the .app  
> file in the code path, and then assumes that all .beam files for this  
> application are located in the same directory - ie does *not* search for  
> them in the path. Could this be what is causing your problem?
>
> / Gunilla

I've not used systools via erlc (I always roll my own tool ;-),
but after some experimentation, I was able to deduce that
the -I <path> flags indeed work. So does -pa and -pz, BTW.
The -I flags are equivalent to the {path, [Path]} option when
calling systools:make_script/2 from Erlang, and if you quote
the path expression, you can use wildcards:

erlc -I "$MYAPPS/lib/*/ebin" mysystem.rel

I believe Fredriks dilemma is that he doesn't want to
have huge applications, and thus split the code into
several subdirectories. This will not work with the
OTP release handling system, as it requires the .beam
files to be in the same place as the .app files (*)
I think there are two approaches to solving the problem:

- Use packages. This will allow you to organize modules
   into a tree of subdirectories under the main application

- Use included applications. This will allow you to use
   .app files as a means to hook into the OTP release
   handler, while still keeping only a few "top" applications
   that effectively include a whole lot of modules.

(*) Obviously, the .beam files can be "patched" by putting
another copy in a directory that's early in the path, but
the original must be in the application's ebin directory.
The .app file cannot be patched, and has to always reside
in the application's ebin/. This is also true for the
application upgrade script (the .appup file).

/Uffe
-- 
Ulf Wiger



More information about the erlang-questions mailing list