Includes

[Pupeno]

On Saturday, 22 de April de 2006 18:40, Serge Aleynikov wrote:
> Pupeno wrote:
> > Where should header files needed for others to use my library go ?
> > I have Erlang on /usr/lib/erlang/ so my project, let's suppose Serlvers,
> > go into:
> > /usr/lib/erlang/serlvers-x.y.z/
> > where x.y.z is the version (0.1.0 now, 0.2.0 soon). Is that right ? wrong
> > ? nobody knows ?
>
> A more traditional location would be:
> /usr/lib/erlang/lib/serlvers-x.y.z/

That's what I meant, it was a typo.

> Though, you have other options, such as:
>
> 1. Assign some other common directory for custom applications, and use
> "-pa PATH" option of the compiler to include the paths to those apps.
>
> 2. Use embedded systems approach (see "Embedded Systems User's Guide")
> for building and distributing your application.  In this case you don't
> need to create "serlvers-x.y.z" folders for different releases, and just
> use "serlvers" in your development environment.  The
> systools:make_script/2, systools:make_tar/2 will take care of including
> paths with proper application versioning.  This makes it quite
> convenient to do an embedded distribution of your app together with the
> Erlang virtual machine on hosts that don't have Erlang installed.  This
> is a more advanced task, and I would suggest that you would experiment
> with only if you need to get a good understanding of the OTP release
> handling principles.
>
> > Then include files would go on:
> > /usr/lib/erlang/serlvers-x.y.z/include/
> > right ?
>
> /usr/lib/erlang/lib/serlvers-x.y.z/include/

Again a typo.

> > How should then the applications using Serlvers include those files ?
> >
>  > -include("/usr/lib/erlang/serlvers-0.1.0/include/dns.hrl"). I don't
>  > think full paths are right here.
>  > -include("serlvers-0.1.0/include/dns.hrl"). and adding -l
>
> /usr/lib/erlang/ at
>
>  > build time ? Then in the next patchlevel serlvers-0.1.1, whatever was
>  > using serlvers won't work.
>
> Refer to section 4.2.4 of the Erlang Reference Manual.
>
> -include("dns.hrl").
>
> and then use the following to compile a source code file:
>
> erlc -I /usr/lib/erlang/lib/serlvers-x.y.z/include ... your_file.erl
>
> Alternatively, use:
>
> -include_lib("serlvers/include/dns.hrl").
>
> in this case you don't need to specify the full path
> "/usr/lib/erlang/lib/serlvers-x.y.z/include" at compile time, as the
> compiler should be able to locate the latest version of your serlvers
> application automatically.
I see; it seems you have to start erl AFTER having put the code there, 
otherwise it doesn't work and that was my problem.

> > And this takes me to a more problematic point: How should header files of
> > project A include header files of project A and project B ?
> >
> > Supouse that I have /usr/lib/erlang/serlvers-x.y.z/include/common.hrl,
> > should dns.hrl -include("common.hrl") ? -include("include/common.hrl") ?
>
> Frankly I don't think it's a good idea, as it makes code analysis more
> confusing, but others may have a different opinion on this coding style.
There's code that already does it.

> > Any help is really appreciated, I am lost here.
>
> Hope this helps.
Yes, it does.

Thank you.
-- 
Pupeno <pupeno@REDACTED> (http://pupeno.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060422/c425100c/attachment.bin>