Currently embuilder will only build if necessary - so it is safe to run multiple times in succession, without doing extra work. Perhaps though this is not the most natural thing - looks like you were expecting it to always build when requested?
We could allow it to receive flags that it passes on to the things being built, but then we'd need to handle configure flags, env flags, etc., and maybe something else I'm forgetting? What then worries me is someone building with a special flag, and forgetting that, and then their system lib can cause problems later. If you manually build it to a non-system location that seems less likely to confuse. Regarding the significant code size shrinkage you saw when removing that iostream line, I wonder if we can figure out an LLVM pass to do it automatically? Clearly right now LLVM's dead code elimination isn't managing to remove that code, but maybe we can improve it, or add hinting or something like that. It would be helpful to try to reduce the iostream case to something standalone that shows the same issue, so we know what to focus on. But if that's hard to do, I can look at libc++ directly. - Alon On Thu, Dec 25, 2014 at 6:26 AM, Floh <[email protected]> wrote: > 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. > -- 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.
