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.
