[erlang-questions] typical project structures / sanity check

Woody Peterson <>
Sat Dec 11 00:54:57 CET 2010


Forwarding this to the list, accidental PM'ing

On Dec 10, 2010, at 12:38 PM, Heinz N. Gies wrote:

> having the standard data structure causes trouble with reltool not  
> finding your application

I guess this is turning into a feature request :) Would it make sense  
for reltool to be able to find your application without following a  
strict directory naming convention? Perhaps an {app_dirs, [{myproject,  
"../"}]} option or the like? Seems like a lot of people start off  
trying to use reltool from within the OTP structure.

Then again, once I started thinking of things in terms of projects and  
apps, I realized I already have a case that could be made for wrapping  
my app in a project. Specifically, I've included an mnesia monitoring  
project as a dependency of the app I want to deploy, when really it's  
a dependency of the deployed production system (not the app logic  
itself).

If anyone argues that the current structure encourages modularity and  
the above 'feature request' therefore doesn't make sense, the next  
question is how to get the word out about how to start a deployment- 
capable project in erlang. A lot of people seem to expect to be able  
to deploy the app they just made as a target system.

-Woody

On Dec 10, 2010, at 12:38 PM, Heinz N. Gies wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> With my limited experience (which is mainly limited to 1 hoby  
> project :P):
>
> having the standard data structure causes trouble with reltool not  
> finding your application unless you include the parent folder of  
> myproject (myproject/../), having all the ebin stuff in a subfolder  
> you can include exactly that subfolder and don't run into the  
> posible problem of having more then one copy of myproject in  
> myproject/../.
>
> then again I might be totally wrong ;)
>
> Regards,
> Heinz
> On Dec 10, 2010, at 21:30 , Woody Peterson wrote:
>
>> Hi all,
>>
>> The short question is: are the project used for a first target  
>> system and a standard OTP app mutually exclusive? In other words,  
>> can a project used to generate a first target system also be the  
>> source for an application, or must that application necessarily be  
>> a subdirectory somewhere, for example /lib/myproject?
>>
>> I started a project (let's call it 'myproject') using the OTP  
>> structure like so:
>>
>> myproject
>> - src
>> - ebin
>> - priv
>> - include
>>
>> Now it's time to deploy, and I want to use rebar/reltool. The  
>> problem is that I have to tell reltool where the 'myproject'  
>> application is. Well, in my case, it's in ~/erlang, but so is a lot  
>> of other stuff, so I don't want to declare that in the  
>> reltool.config lib_dirs. I asked around on the rebar mailing list,  
>> and it seems that the best solution is to move /src to /apps/ 
>> myproject/src and put /apps in lib_dirs. Well, now my main app  
>> doesn't follow the OTP conventions anymore :(
>>
>> Erlang/OTP in Action / sinan (written by the same people) use the  
>> following project directory structure:
>>
>> myproject
>> - _build.cfg
>> - lib
>> -- myapp
>> --- doc
>> --- ebin
>> --- include
>> --- src
>>
>> This clearly separates the 'project' from the component  
>> application, but I haven't yet heard it explicitly said that these  
>> need to be separated in order to deploy in a standard manner.
>>
>> So: do you always structure projects like this, or is there a way I  
>> can deploy my single OTP app using reltool (w/o breaking it's  
>> current OTP structure)?
>>
>> Thanks,
>>
>> -Woody
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Darwin)
>
> iEYEARECAAYFAk0Cj60ACgkQHwrnTfuX/fUGFwCfUoiUEY309KB4/N4RuxAy9x5r
> u64AoJN4qyefXOvBp/W/QSHy+C5DebOu
> =us+k
> -----END PGP SIGNATURE-----



More information about the erlang-questions mailing list