On 29/10/2014 07:23, Brion Vibber wrote:
> 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
Yes. This is much preferable to automagic downloads especially if they
mean -S USE_SDL2=1.
>
> ... that would also 'just work' with autoconf-based projects.
>
Not everyone uses autoconf, which BTW, many people feel is a giant hack
to paper over more fundamental issues such as failure of tools to follow
standard practices.
On 29/10/2014 06:27, Jukka Jylänki 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.
I don't understand what you mean by "check the -L paths manually". In
most compile/link tools following a search path and using default
locations when nothing is found on them is a fundamental part of the
linker's task. Why so averse to having emlink do this? Anybody familiar
with compilers will expect this behavior and will be surprised by its
absence.
>
> 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.
How does -S USE_SDL=2 allow you to build dependencies?
I agree that automatic downloads greatly raise the cost of a mistake in
a -L specification. The solution is explicit downloading as suggested by
Brion and following standard compile/link practices, instead of
inventing something entirely new.
There are those of us who wish to use tools beside autoconf and look
with distaste at needing a special version of make. If you would just
follow standard practices, those may not be necessary.
>
> 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 thought libGLESv2 was built into the emsdk. Are you proposing making
it subject to automagic downloading?
Please stop this and follow standard compiler practices. We are quite
capable of knowing which libraries we want to use and running "emports
install" to get them and specifying -lfoo on our command lines, which is
what we have to do for native builds anyway.
As I wrote yesterday, the more you diverge from standard practices the
harder it becomes to use other build tools.
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.
