[erlang-questions] passing an include path to escript

[Angel]

Hi

When a i run an "escript" script many times I use an static erlang node 
where the codepaths cover all my needs and delegate all work to it so
escript rol is just to parse arguments, and call remote functions.

Being new i was simple for me and also enough complex to learng new aspects of 
erlang.

Some other experiments incluyed using remote code server facilities, avoiding 
to manage NFS paths for erlang directories and the need to load modified code
on all nodes sending binaries if NFS was not available.

Notice for everyone testing remote code server.

(tested on R12)
If you spawn erlag nodes via ssh with remote code loading options, some nodes 
can timeout before finish startup sequence. (On R12..) The slave module 
currently didnt allow you to change timeout (default 30 sec), so you have to 
make a custom versión.


/angel

On Viernes, 22 de Enero de 2010 10:38:22 zabrane Mikael escribió:
> Hi Sergey,
> 
> As "Nick Genrakines" show me the trick, here is a working solution:
> 
> 1. assume your code lives inside "mycode" directory
> 2. assume your .hrl lives inside an "include" directory
> mycode
> 
> |________include: my.hrl
> 
> 3. Then, your escript could simply include that .hrl like this:
> 
> #!/usr/bin/env escript
> %% -*- erlang -*-
> %%! -pz ../mycode ebin
> 
> -include_lib("mycode/include/my.hrl").
> 
> Regards
> Zabrane
> 
> 
> 2010/1/22 Sergey Samokhin <ad.sergey@REDACTED>
> 
> > On Tue, Dec 1, 2009 at 8:37 PM, zabrane Mikael <zabrane3@REDACTED> wrote:
> > > Hi List !
> > >
> > > I'm facing the same issue as "Wojtek" here:
> >
> > http://forum.trapexit.org/viewtopic.php?p=48544&sid=d7fe0c082bbea7b130d30
> >713a2925491
> >
> > > Could someone please,  show us a clean way to add relative paths to our
> > > ".hrl"files which are outside "lib_dir"?
> >
> > Does anybody know, are there any plans on allowing "include" to be
> > used inside escripts?
> >
> > I'm writing a small library for parsing CLI arguments. I think
> > specifications looks much simplier to understand,
> > if they a list of records:
> >
> > Specs =
> > [
> >    #opt{long_name = help,
> >           short_name = h,
> >           type = boolean},
> >    #opt{long_name = version,
> >           short_name = v,
> >           type = boolean,
> >           validator = fun(_Val) -> ok end}
> > ]
> >
> > than a list of tuples:
> >
> > Specs =
> >    [{help, [{short_name, h}, {type, boolean}]},
> >     {version, [{short_name, v}, {type, boolean}, {validator,
> > fun(_Val) -> ok end}]]
> >
> > Currently the only way to specify which options to get is by using
> > list of tuples.
> >
> > --
> > Sergey
>