On 18/11/2014 07:50, Jukka Jylänki wrote: > > 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. Thanks for summarizing so nicely.
I agree whole-heartedly with 1, 2 & 3. I don't fully understand the objections to having -lfoo link to library_foo.js. That fact that the library may actually be named library_foo.js seems like an implementation detail. Why not use the standard names for the libraries, e.g. libGLESv2.js instead of library_glesv2.js? (Actually there is no such library so this is not a good example. I see only library_gl.js which I suppose has both GL & GLES entry points.) As for the name "overloading", it doesn't seem to be a problem for native compilers, why is it a problem for Emscripten? In a Unix-like system's /lib I see for example such generic names as libm, libutil, libcheck, libpthread, etc. > > 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. +1. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -- 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.
