Sat Apr 22 21:46:56 CEST 2006
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:
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 ?
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.
> 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:
> 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.
Pupeno <> (http://pupeno.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the erlang-questions