Sounds good, nice summary. - Alon
On Mon, Nov 17, 2014 at 2:50 PM, Jukka Jylänki <[email protected]> wrote: > 2014-11-17 23:26 GMT+02:00 Brion Vibber <[email protected]>: > >> Is there any way we could have -lfoo link in a JS library called >> 'library_foo.js' if there's no matching libfoo.bc/.lib/.so/.dylib in the >> library path? >> >> In that case, the JS library implementations could simply be renamed to >> match their native equivalents, and if port *installation* is manual there >> should be no surprises... >> >> > If we overload -lfoo to link to library_foo.js, it interacts with more > than just the ports (and actually it does not interact with the ports at > all, since none of the ports we currently have contain any library_x.js > files, they are currently all built only from C sources). There are several > js library files in paths $EMSCRIPTEN/src/library_x.js. That is why I don't > like the approach, and the explicit -lx.js is safer, because otherwise we > would be overloading things like -luuid, -ltrace, -lsignals, -lsdl, -lpath, > -lhtml5, -lgc, -lfs, -lbrowser, -lasync to name some of the more generic > ones. Instead, if the suffix is required in -lx.js, then we can safely add > -L$EMSCRIPTEN/src/ as a default system library, and walk towards a future > path where we start dropping autolinking to each file > $EMSCRIPTEN/src/library_x.js that we currently do. > > So, my proposal is that: > 1. Add -L/path/to/emscripten/built/ports/output/libs to the list of > hardcoded Emscripten system library directories as the LAST item. > 2. Never perform automatic download of a ports based on command line > flags, but have a separate command line utility 'emports install sdl2' (the > name and syntax can be discussed, just throwing some words in as example) > which downloads and builds a port. After this is done, because of 1), it's > only needed to pass the appropriate -lportName (e.g. -lSDL2) will link to > that port. > 3. Add -L$EMSCRIPTEN/src to the list of hardcoded Emscripten system > library directories as the LAST item after 1). > 4. Add -lx.js to mean "--js-library x.js" which is looked up in the > directories specified by -L. > > Some time later/as a separate step, we can then perform the following: > 5. Add an explicit blacklist feature to allow dropping autolinked JS > libraries that user does not want: -s > NO_JS_LIBS=['library_sdl.js','library_jansson.js'] > 6. Start dropping some of the more uncommon JS libs from being > autolinked (library_jansson.js, library_xlib.js, library_gc.js, and so on). > Currently here is the list of libs each codebase always links to: > https://github.com/kripken/emscripten/blob/master/src/modules.js#L428 . > In my view, we should only autolink to libraries that are core Emscripten > ones which only introduce symbols that can't conflict (emscripten_xxx > ones). When people want to link to these, they need to issue a directive > like -ljansson.js -lgc.js and so on. > > The steps 1 and 2 should cover the ports, then steps 3 and 4 should make > linking look more "standard" looking by reusing -l and -L, and 5 and 6 give > future development paths for other libs that we currently hand-implement > but in the future might compile from asm.js. With these, we should have a > strategy that helps combat the list from > https://github.com/kripken/emscripten/blob/master/src/modules.js#L428 > from growing. > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
