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. 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. -- 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.
