As a user, I'd also be inclined to want a separate package manager/installer for the ports rather than having them downloaded magically during compilation/linking.
Something like: # to install relevant packages emports install SDL2 zlib freetype # to compile, make sure to reference the libs explicitly emcc mystuff.c -lSDL2 -lz -lft -o mystuff.js As for the linker flags and magic versus regular -lWhatever... Super-ideally, a magic build flag like --js-library or -lglut.js vs -lglut could be provided by something like pkg-config, and that would also 'just work' with autoconf-based projects. For example, proper linking to a native libogg as installed on my Mac via Homebrew can be determined with pkg-config: $ pkg-config --libs ogg -L/usr/local/Cellar/libogg/1.3.2/lib -logg so the special-ports version of glut could specify the magic --js-library in the pkg-config file which would be retrieved via `pkg-config --libs glut` inside an emconfigure or emmake environment. Of course not every package comes with pkg-config metadata... Not sure if it'd be better to add custom entries or provide a similar interface on the port manager program (`emports --cflags SDL2` etc). I'd also kind of prefer for the ports to be installed on a per-project basis as well, like npm packages, rather than globally, cause I like clean build environments. That might require explicitly setting a base path explicitly. -- brion vibber (brion @ pobox.com / bvibber @ wikimedia.org) On Tue, Oct 28, 2014 at 2:27 PM, Jukka Jylänki <[email protected]> wrote: > The current -s USE_SDL2=1 option is overloaded to download the SDL2 port > on demand. If we reused -lSDL2 for that, it'd mean that we would spin off > http downloads on demand. What if someone actually does have a library > called libSDL2.a on his system that he built manually (a lot of existing > users already do) and he instead wants to link to that? This means we > should check the -L paths manually and only revert to downloading if none > of those paths contained any of predefined names libSDL2.a, libSDL2.so, > libSDL2.dylib, libSDL2.lib, SDL2.lib or SDL2.a. That would kind of work, > and users who built SDL2 manually would then be able to link to the library > they built themselves, and users who did not, would get the download on > demand. > > However this scheme is so brittle that it's just picking blood from your > own nose, because it has the unfortunate effect that if there are any > mistakes in a build (-L directories were passed wrong, an earlier build > step had failed to produce a libSDL2.a file to some expected location, a > build clean directive has been called to SDL2 before building main, and > there's no dependency tracking, or something else), we would not be able to > detect any of these, but instead would proceed to happily assuming that the > user was not looking to link to his own SDL2, but we should download and > build the ports SDL2 on demand. I can imagine someone mistaking a relative > link path -L../../sdl2/lib when he was intending a -L../sdl2/lib or > something else, and getting Emscripten downloading files off the web as a > random result. This is not very robust nor explicit and I don't think we > should go there. > > The same rationale applies for GLES, GLUT, GLFW and others, where I think > we should not overload -lGLESv2, -lGLUT and so on to mean to silently link > to Emscripten-provided ones if others are not present. > > I somewhat dislike the current behavior of -s USE_SDL2=1 at link time for > downloading and building SDL2 on demand. This is because the scheme does > not feel scalable. What should we do with other potential libraries like > FreeType and Regal and zlib and other common ones that people are using? I > think it would be better if we had separate scripts > $EMSCRIPTEN/ports/install_{sdl2, freetype, zlib, ...}.py that would > download and build the appropriate ports to the cache - and only do so when > user explicitly runs one of those scripts, and Emscripten would never do it > during compilation or linking. In that scenario, people could pass > "-L~/.emscripten_ports/lib -lSDL2" to link, or we could even allow omitting > -L ~/.emscripten_ports/lib as a link directory and always treat that as a > system built-in link directory that exists and is searched last. There > would not be any confusion there, because a copy of SDL2 would never appear > there unless someone explicitly had installed one via a call to > $EMSCRIPTEN/ports/install_sdl2.py, so the danger of silently doing the > wrong fallback would not exist. > > For linking to the built-in provided src/library_x.js files, I'm leaning > on removing the current autolinking support to any of these, but how about > if we dropped the --js-library and instead did "-lglut.js" ("-lsdl.js" and > so on) to mean to link to the file "library_glut.js" that should exist > somewhere in the filesystem in the -L paths (searching $EMSCRIPTEN/src as > last one)? The suffix .js to -l would make it explicit that one is looking > to link to a library_x.js file. That would be a more consistent way instead > of adding heuristics that "-lGLESv2 should map to library_gl.js, -lGLUT > should map to library_glut.js, -lal, -lsoft_oal should map to > library_al.js, ..." and so on. > > Jukka > > 2014-10-28 22:33 GMT+02:00 Alon Zakai <[email protected]>: > >> If Jukka is ok with that, I am too. I'm not that picky, nor knowledgeable >> about C toolchain things. >> >> - Alon >> >> >> On Mon, Oct 27, 2014 at 7:21 PM, Bruce Mitchener < >> [email protected]> wrote: >> >>> On Tue, Oct 28, 2014 at 9:07 AM, Mark Callow <[email protected] >>> > wrote: >>> >>>> On 24/10/2014 05:18, Alon Zakai wrote: >>>> >>>> We did consider using -lSDL2, but Jukka convinced me that it was too >>>> brittle - could have confusion with a local library of that name, etc. So >>>> -s USE_SDL=2 is an explicit way to say "use the ports version of this", >>>> while -lSDL2 is "use a local copy of it". >>>> >>>> I think that is a safer default behavior, but I wouldn't be opposed >>>> to having an option to treat -lSDL2 as using it from ports. >>>> >>>> The more Emscripten diverges from the standard behavior of compiler >>>> tool chains, the harder it is to adapt other build tools to work with it. >>>> The issues I am having with GYP are symptomatic of this. >>>> >>>> In the specific case of "-s USE_SDL=2" vs the standard "-lSDL2", if >>>> the latter is brittle, why isn't -lc brittle for regular C/C++ compilers? >>>> There is a well defined search path; directories specified with -L come >>>> before the default directories. In other words, it is not brittle at all. >>>> If you specify a -L that contains a library with the same name as a system >>>> library, you are expected to know what you are doing. >>>> >>>> Emscripten should likewise search any specified -L directories and, if >>>> a specified library isn't found, then it should search its built-in >>>> libraries and equivalent functions and then the ports. >>>> >>>> It should also not issue errors that a library specified with -l can't >>>> be found, if that libraries functionality is built into Emscripten. E.g. >>>> specifying -lGLESv2 should not cause emlink to spit out "Error: >>>> libGLESv2.a: File not Found" (or something like that) as the GLESv2 >>>> functions are all included in Emscripten. >>>> >>>> This changes would make Emscripten much more friendly to other build >>>> tools. >>>> >>> >>> For what little it is worth, this sounds good / right to me. >>> >>> - Bruce >>> >>> >>> -- >>> 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. >> > > -- > 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.
