<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 13, 2015 at 11:59 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
On 10/13/2015 11:31 AM, Vlad Dumitrescu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
* one will now be forced to compile within an environment identical to<br>
the target - so that all the preprocessor conditions resolve to the<br>
right values. This includes having all dependencies (even transitive?)<br>
installed in the development environment and the build server, not only<br>
OTP. Is the application descriptor enough to define that, or does it<br>
need to be extended? Maybe the new package manager is supposed to help here?<br>
</blockquote>
<br></span>
People already do these things, although in a more awkward way, as explained in the EEP. I don't foresee the ecosystem to change much just because the preprocessor lets you do it more easily.<span><br></span></blockquote><div><br></div><div>I'm not sure about that. If something is easy to do, then more people will use it. Also, people are very creative :-) </div><div><br></div><div>What the is_module() guard does is creates a compile-time and run-time dependency to the referred module, which has to be present in the code path both times. If it's not there (maybe because I forgot to include a dependency, or I use the wrong runtime), you will not get any error message (like include_lib), but a beam file with wrong content. One can add tests to make sure the beam is ok, but if the dependencies are fetched in source form and built locally, their tests might not be run every time I build my code... </div><div><br></div><div>If the -if conditions were to be evaluated at load-time, and the function table patched accordingly, then I think that the result would be the same at run-time and the development much simpler. </div><div><br></div><div>BTW, when building a cowboy extension or add-on, is it usual to have the whole cowboy and dependencies installed together with the compiler, on TravisCI? I suppose that would be a use case where this can make a difference.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* if one targets multiple versions, then the set-up of the development<br>
environment is unwieldy unless one needs to use something like kerl to<br>
manage the multiple environments. It feels a bit wrong to have OTP<br>
depend indirectly on a third party application... I think that OTP<br>
should provide tools to help with that.<br>
</blockquote>
<br></span>
I'm not sure what you think something inside OTP can do better than something outside OTP. Can you clarify your thoughts on that?<br></blockquote><div><br></div><div>I didn't say that OTP tools are better and a prolific third-party ecosystem is very good. But if the base system makes it harder to do some things, in practice forcing the use of a third-party tool that may not be maintained at the same rate and quality level, it doesn't give a good feeling. A dependency from a stable component to an unstable one makes them both unstable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think it's very good that so much of the ecosystem relies on third party tools and libraries. It's a sign that Erlang is thriving. It's no longer the sole responsibility of the OTP team to provide everything.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* if not deploying an OTP application or a full system, one can't know<br>
if the target will fulfill the expected conditions - what about compiled<br>
escripts?<br>
</blockquote>
<br></span>
Those tend to be compiled for the lowest supported version to make sure they work "everywhere". I don't think this EEP will change anything about that.</blockquote><div><br></div><div>Maybe not right now, but it is possible that the way APIs evolve will change, affecting the usage. I don't know, that's why I said at the beginning that I am worried, not that this is a catastrophy. </div><div><br></div><div>regards,</div><div>Vlad</div><div><br></div><div> </div><div><br></div><div><br></div></div></div></div>