[eeps] New - EEP 44: Additional preprocessor directives

[Vlad Dumitrescu]

On Tue, Oct 13, 2015 at 11:59 AM, Loïc Hoguin <essen@REDACTED> wrote:

>
> On 10/13/2015 11:31 AM, Vlad Dumitrescu wrote:
>
>>
>> * one will now be forced to compile within an environment identical to
>> the target - so that all the preprocessor conditions resolve to the
>> right values. This includes having all dependencies (even transitive?)
>> installed in the development environment and the build server, not only
>> OTP. Is the application descriptor enough to define that, or does it
>> need to be extended? Maybe the new package manager is supposed to help
>> here?
>>
>
> 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.
>

I'm not sure about that. If something is easy to do, then more people will
use it. Also, people are very creative :-)

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...

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.

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.



> * if one targets multiple versions, then the set-up of the development
>> environment is unwieldy unless one needs to use something like kerl to
>> manage the multiple environments. It feels a bit wrong to have OTP
>> depend indirectly on a third party application... I think that OTP
>> should provide tools to help with that.
>>
>
> I'm not sure what you think something inside OTP can do better than
> something outside OTP. Can you clarify your thoughts on that?
>

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.

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.
>
> * if not deploying an OTP application or a full system, one can't know
>> if the target will fulfill the expected conditions - what about compiled
>> escripts?
>>
>
> 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.


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.

regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20151013/281f3425/attachment.htm>