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.
