I think the best solution would be to allow embuilder.py to accept preprocessor defines (or may be even general compiler/linker cmdline args which are forwarded), e.g.:
./embuilder.py build libcxx -- -DBLABLA=1 Then there could be a set of standard defines which switch on/off certain features in the libs built by embuilder.py In our own build systems, we could then add embuilder.py as a pre-built-step with specific preprocessor defines...? Cheers, -Floh. Am Mittwoch, 24. Dezember 2014 14:41:03 UTC+1 schrieb Floh: > > 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]> 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]. >>> 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.
