multiple drivers, linking problems

Eric Cestari ecestari at gmail.com
Mon Oct 4 15:46:56 EDT 2010


> The modularity this encourages is a Good
> Thing and also makes it _possible_ to even contemplate doing hot
> upgrades of native code.

Yes I understand the point, and I agree. That's also the opiniated part I was referring to :)
In that case I will extract small OTP apps for each of the drivers and make them part of the rebar build.

Thanks for the feedback.
Eric
Le 4 oct. 2010 à 21:30, David Smith a écrit :

> As noted previously, rebar is really designed (by and large) around
> the idea of compiling multiple (or singular) OTP apps. While I
> understand what you're trying to do with ejabberd, I would prefer not
> to further complicate the port/NIF compilation code with a bunch of
> conditional logic to deal with many ports/NIFs per single app.
> Ejabberd is the exception here, not the rule; either those port
> drivers need to be merged into a single port (blech!), or they should
> be broken out by Erlang apps.
> 
> If you look at the Erlang/OTP source or just about every other
> Erlang-based system, you will see that the general tendency is to have
> a single port/NIF per app. The modularity this encourages is a Good
> Thing and also makes it _possible_ to even contemplate doing hot
> upgrades of native code.
> 
> D.




More information about the rebar mailing list