__EMSCRIPTEN_major/minor/tiny__ defined for compile js ?

[Thaina]

There is an major update about EMVAL related functionality in emscripten in version 2 and 3. And I am in needed to write a js code that can support both version

Something like this

/*global requireHandle, _emval_register, _emval_run_destructors*/

var myLib = {
  JS_GetDate__deps: ['_emval_register'],
  JS_GetDate: function() {
    return __emval_register(new Date());
  },
  
  JS_GetTime__deps: ['$requireHandle'],
  JS_GetTime: function(/** @type {Date} */date) {
    date = requireHandle(date);
    return date.getTime();
  },
  
  JS_Free__deps: ['_emval_run_destructors'],
  JS_Free: function(/** @type {Date} */date) {
    __emval_run_destructors(date);
  },
}

mergeInto(LibraryManager.library,myLib);

I wish I could writing a code like #if EMSCRIPTEN_VERSION < 2.2.0 to switch between code that depend and use _emval_register and code that depend and use use Emval object when anyone bring this code to use in difference emscripten version

/*global requireHandle, _emval_register, _emval_run_destructors*/

var myLib = {
#if EMSCRIPTEN_VERSION < 2.2.0
  JS_GetDate__deps: ['_emval_register'],
#endif
  JS_GetDate: function() {
#if EMSCRIPTEN_VERSION < 2.2.0
    return __emval_register(new Date());
#else
    return Emval.toHandle(new Date());
#endif
  },
  
#if EMSCRIPTEN_VERSION < 2.2.0
  JS_GetTime__deps: ['$requireHandle'],
#endif
  JS_GetTime: function(/** @type {Date} */date) {
#if EMSCRIPTEN_VERSION < 2.2.0
    date = requireHandle(date);
#else
    date = Emval.toValue(date);
#endif
    return date.getTime();
  },
  
  JS_Free__deps: ['_emval_run_destructors'],
  JS_Free: function(/** @type {Date} */date) {
    __emval_run_destructors(date);
  },
}

mergeInto(LibraryManager.library,myLib);

Is it already possible? If not is it could be possible?

Alternatively, are there any compiler flag I could check to see if there is Emval object defined or I need to use _emval_register instead ?

[kripken]

You do have access to EMSCRIPTEN_VERSION in js library files. But it is a string like "3.1.36-git" or "3.1.36", so <, > comparisons would need to go through a helper function I guess.

[sbc100]

You might also want look into writing your JS code directly in the C/C++ source using EM_JS

[juj]

Thanks for this neat snippet @Thaina . I wonder where the .slice(0,4) part comes from?

I ended up using

#if EMSCRIPTEN_VERSION.split('.').map(parseInt) < [3,1,35]

in my wasm_webgpu bindings library.

[Thaina]

Thanks for this neat snippet @Thaina . I wonder where the .slice(0,4) part comes from?

I ended up using

#if EMSCRIPTEN_VERSION.split('.').map(parseInt) < [3,1,35]

in my wasm_webgpu bindings library.

slice(0,4) means I would pick only 4 item of the split that most likely be a version number to parse as integer

[juj]

Big gotcha I found out today: #if EMSCRIPTEN_VERSION.split('.').map(parseInt) < [3,1,35] as I presented above does not actually work at all!

Instead, one must use

#if EMSCRIPTEN_VERSION.split('.').map(parseFloat) < [3,1,35]

Details of why parseInt does not work, but parseFloat does, can be found at https://stackoverflow.com/questions/262427/why-does-parseint-yield-nan-with-arraymap

[juj]

Actually, now that I look into this, the whole .map(parseInt/Float) thing doesn't work at all. When I read the above code first, I assumed that arrays had a lexicographic compare, but that is not the case.

Rather the arrays get converted back to strings, so this achieves nothing. https://stackoverflow.com/questions/8328908/javascript-surprising-array-comparison