[erlang-questions] App supporting several Erlang releases

[Mazen Harake]

IMHO.

Trying to "cover" all versions sounds like the kind of nightmare I could 
wake up to in the middle of the night. Some call it "maintenance 
nightmare", I just call it "waste of time".

If you update your software in anyway you will have to put in these 
quirks in every piece of code that isn't always backwards compatible.

It feels a bit like handling python2 or python3 in your code I.e: wrong.

My 2 cents? Just split the versions, one pre R13 and one R13+... or 
discard one (say only works with R13+ or whatever)

/Mazen


On 17/01/2011 20:22, Jachym Holecek wrote:
> # Vlad Dumitrescu 2011-01-17:
>> I have some code that I'd like to be able to run in R12 or later, depending
>> on what the user has installed. The problem is that some OTP APIs have
>> changed in R13 and R14, making the task not straightforward. Unfortunately
>> it's not only code that is affected (that would be possible to fix by
>> checking the actual version), but also hrl files have moved or been created
>> in the meanwhile. The most acute example is about eunit, where for example
>> in R13 eunit.hrl moved from eunit/src to eunit/include and the
>> eunit_listener behaviour was added.
>>
>> Is there any way to address this in a more reasonable way than duplicating
>> the affected module and fiddling with the code path at load time?
> IIRC what a colleague did some time ago to solve similar problem was
> to extract OTP release from ${prefix}/lib/erlang/releases/RELEASES
> (or was it ERTS version? -- they're both there anyway) and use that
> to define a macro from erlc commandline, then add ifdefs to affected
> files that would include headers from the right location. I'm not
> sure this was actually used in the end, but it worked.
>
> So -- depends on your build system and the amount of dark trickery
> you're willing to tolerate in your codebase :-).
>
> Regards,
> 	-- Jachym
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>