I think a complete modularisation isn't necessary, since most static lib code should only be pulled in if used.
The biggest 'cheap' gain comes from removing a single line of code in libcxx/iostream.cpp where a static object is constructed to initialize the iostream system: // ios_base::Init __start_std_streams; This is a hack of course, I don't know what would happen if my code would try to call iostream stuff, but the size savings are quite dramatical, about 350kByte (uncompressed) on the JS files, for the (quite small) Oryol demos, this is really a big win: 713102 -> 360222 Clear.js 473029 -> 119561 CoreHello.js 1068208 -> 770951 DDSCubeMap.js 1070180 -> 773362 DDSTextureLoading.js 814544 -> 489893 DebugText.js 962358 -> 666109 DrawCallPerf.js 780651 -> 427877 FullscreenQuad.js 970307 -> 673521 GPUParticles.js 535236 -> 182208 HTTPClientSample.js 643000 -> 347095 IOQueueSample.js 923865 -> 602929 InfiniteSpheres.js 963751 -> 667261 Instancing.js 925094 -> 604076 PBRendering.js 901544 -> 580764 PackedNormals.js 928600 -> 627626 Paclone.js 941672 -> 645518 Sensors.js 901762 -> 580639 Shapes.js 920948 -> 600069 SimpleRenderTarget.js 908263 -> 608208 SynthTest.js 967160 -> 671005 TestInput.js 1383053 -> 1098855 TestNanoVG.js 871810 -> 574982 TextureFloat.js 842690 -> 493159 Triangle.js 948571 -> 652293 VertexTexture.js 446748 -> 85235 hello.js The .mem files are reduced by about 14kByte (uncompressed): 42776 -> 28552 Clear.html.mem 16616 -> 2376 CoreHello.html.mem 82736 -> 69288 DDSCubeMap.html.mem 83368 -> 69920 DDSTextureLoading.html.mem 70864 -> 56640 DebugText.html.mem 77352 -> 63904 DrawCallPerf.html.mem 57040 -> 42816 FullscreenQuad.html.mem 89592 -> 76144 GPUParticles.html.mem 30712 -> 16480 HTTPClientSample.html.mem 42808 -> 29352 IOQueueSample.html.mem 65296 -> 51168 InfiniteSpheres.html.mem 77280 -> 63832 Instancing.html.mem 82224 -> 68096 PBRendering.html.mem 63040 -> 48912 PackedNormals.html.mem 222536 -> 208992 Paclone.html.mem 77160 -> 63712 Sensors.html.mem 63008 -> 48880 Shapes.html.mem 66368 -> 52240 SimpleRenderTarget.html.mem 80096 -> 66552 SynthTest.html.mem 80160 -> 66728 TestInput.html.mem 74576 -> 61408 TestNanoVG.html.mem 79784 -> 66336 TextureFloat.html.mem 60576 -> 46448 Triangle.html.mem 83800 -> 70352 VertexTexture.html.mem 15160 -> 544 hello.html.mem By the way, I currently have to manually delete the libcxx.bc file from .emscripten-cache before embuilder.py actually recompiled the lib after changing the source code. I'll play around with this a bit more over the next days and try to find a clean solution. If it is possible to easily link a non-standard libcxx, may be the best solution would be to compile 2 libcxx, the standard one with iostream, and a 'libcxx_no_iostream.bc' without the iostream initialization. It would be good though to get a linker error when the user code tries to use iostream functionality... I'm also not sure whether this should be an official emscripten feature at all, if it remains a 'hack' which is not really C++ compatible, then it is may be better to treat this as a size-optimization trick and only put a how-to into the emscripten docs? Cheers (and merry christmas), -Floh. Am Freitag, 19. Dezember 2014 22:57:23 UTC+1 schrieb Alon Zakai: > > Well, the issue there is that we would need to refactor libc++ into > modules, or something like that? Or add ifdefing to libc++. Unless there is > a better way that I can't think of. > > The system builder tool just offers a way to ask for a system component to > be built, it currently can't do anything the system couldn't already do. > > But, if we find a way to modularize libc++, then an option for the system > builder would indeed be the right place to put it. > > - Alon > > > On Fri, Dec 19, 2014 at 1:25 PM, Floh <[email protected] <javascript:>> > wrote: >> >> Will this allow is to build libc++ without iostream constructors as >> discussed earlier? (https://github.com/kripken/emscripten/issues/2785) >> >> Cheers, >> -Floh. >> >> Am Donnerstag, 18. Dezember 2014 23:33:20 UTC+1 schrieb Alon Zakai: >> >>> I pushed to incoming a "system builder" tool, embuilder.py It lets you >>> manually ask that things be built, like libc, the native optimizer, zlib >>> from ports, etc. >>> >>> embuilder.py -help shows the available operations. >>> >>> This addresses part of the requests for a more manual way to build >>> things from emscripten ports. It also allows other manual building, which I >>> have heard some projects have been doing, of things like libc, etc. >>> >>> For example, you might do this: >>> >>> ./embuilder.py build zlib >>> ./emcc code.cpp -s USE_ZLIB=1 >>> >>> and the first command will already ensure that zlib is fetched and built. >>> >>> Thoughts? >>> >>> - Alon >>> >>> -- >> 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] <javascript:>. >> 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.
