All of this sounds very reasonable to me. - Alon
On Mon, Nov 17, 2014 at 1:26 PM, Brion Vibber <[email protected]> wrote: > On Mon, Nov 17, 2014 at 1:17 PM, Jukka Jylänki <[email protected]> wrote: > >> >> 2014-11-11 8:39 GMT+02:00 Mark Callow <[email protected]>: >> >>> juj's objection to library search paths in the end is only about the >>> cost of a mistaken search path given as part of the command. I don't think >>> it is that big a deal. Following the standard practice of other compilers >>> is much more important and makes Emscripten usable with a wider range of >>> build tools. The cost can be minimized by either requiring manual download >>> of ports (my preference) or asking for confirmation when automatically >>> starting a download. >>> >> >> I am arguing against the practice that e.g. -lSDL2 would trigger a >> download-on-demand if none of the -L paths did not contain a matching file. >> That is not standard practice in any compiler environment that I know of. >> Like I mentioned before, I am also in favor of the method that downloading >> the ports is always manual and requires running a separate install command >> first. I don't like going the route of adding interactive confirmation >> prompts to the compilation progress, but perhaps we could mitigate the >> issue by matching -lXXX to a known port and issuing a hint message that >> explains that a library exists in the ports. >> > > +1 I like this. Explicit installation and a nice hint message if libraries > matching a known signature not found. > > I am also arguing against string-matching "-lSDL -> library_sdl.js, -lm -> >> /dev/nul, -lal -> library_openal.js, -loal -> library_openal.js, -lsoft_oal >> -> library_openal.js, -lGLESv2 -> library_gl.js" and so on, because that >> will be error prone and a maintenance mess. I like the idea of reusing >> -lxxx.js to mean --js-library library_xxx.js and reusing -L directories to >> also search for paths in -lxxx.js, because the explicit suffix .js ensures >> there won't be any problems or backwards issues with existing builds >> systems. >> > > 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... > > -- brion > > -- > 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.
