On Mon, Nov 10, 2014 at 10:39 PM, Mark Callow <[email protected]> wrote:
> On 07/11/2014 02:45, Alon Zakai wrote: > > Please file an issue with a testcase for SDL1 and 2 both being linked > in, on e.g. browser.test_sdl2_jpeg I don't see that happen. > > I am still using Emscripten 1.22.0 together with gsathya's build of > libSDL2. If I see evidence of SDL1 being included once the SDL2 port is > mainstream, I'll open an issue. > > > Regarding the linking debate, would using pkg-config be a solution that > everyone is happy with? Using pkg-config is pretty standard stuff, and we > could make it emit USE_SDL=2 etc. under the hood, as internal flags that > users would never see. > > I don't really see how pkg-config helps. It just looks like another set of > files you'll have to maintain. It certainly doesn't help my situation with > MS visual studio configs. > I don't know enough about MS Visual Studio to know what would work well there. But for typical makefiles, I was thinking that `empkg-config sdl2 --cflags` would be more standard and nice than -s USE_SDL=2 which is completely emscripten-specific. > If the ports are installed in a standard place within the Emscripten > sdk, it seems much easier just to make emlink (emcc) search that place for > includes and libraries as well as searching the location of the libraries > that are included as standard with Emscripten. > 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 don't have a strong opinion about this part. However, it would be additional work to do it (implement it, add testing, etc.), so in addition to deciding if we want to do it, we would need someone with time to spend on it. > You mentioned that the compiled port would be put into Emscripten's > cache. How does that differ from generating a bitcode library from it and > saving it in a directory searched by the linker? > The cache is automatically managed by emscripten, for example, we clear it on version updates automatically. This avoids e.g. a fastcomp update that uses different bitcode, in which case if the cache were not cleared, an error would happen. We could of course add such versioning of another location for the linker to search, but it adds some complexity to the design. (Again, though, I'm not opposed categorically.) > While on the subject of library search paths, could you also please > change emcc/emlink to not emit errors when it can't find libraries > specified on the command line because they happen to be included in > Emscripten. The most obvious examples of this are libGLESv2 and libEGL. > Please file an issue with the details there (not sure exactly what you mean from that description). - Alon > 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. > -- 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.
