> However, when you do the "activate" step it populates the .emscripten file with the relevant paths - can you get it from there for your build system?
Yes, I guess I can figure something out along those lines :) I'm planning to rework my emscripten integration so that it plays better with the emsdk (e.g. I'm currently not supporting easily switching between SDK versions). One thing that would be nice would be quering the current SDK path a'la the Xcode command line tools xcode-select and xcrun. The xcode-select tool is a bit similar to "emsdk activate", I can make one of many installed macOS/iOS/tvOS... SDKs the active one for the other command line tools... And xcrun has an option to show the currently active SDK path, for instance: > xcrun --show-sdk-path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk ...and the output is in an "automation-friendly format", just the path and nothing else. So something like this would be nice: > emsdk show-sdk-path /Users/floh/.../fastcomp/3b8cff670e9233a6623563add831647e8689a86b/emscripten/ On Friday, 24 May 2019 19:13:34 UTC+2, Alon Zakai wrote: > > Thanks for the feedback! > > The reason we extract into a different directory is so that (1) you can > have multiple builds and switch between them, and (2) when you > install/activate a version, we know if we need to unzip it or not - if the > directory exists and is populated, then we have nothing to do. Otherwise > we'd always need to unzip the files. But yeah, I do see your point that it > makes it harder to just use the build. However, when you do the "activate" > step it populates the .emscripten file with the relevant paths - can you > get it from there for your build system? > > The lkgr.json warning should be fixed on emsdk master currently. > > > On Fri, May 24, 2019 at 10:03 AM Floh <[email protected] <javascript:>> > wrote: > >> I'm testing with my cmake-based build setup and I'm having trouble with >> the new directory structure of the SDK. >> >> I need to know the path to the emscripten installation in various places >> (among others, a cmake toolchain file), but as far as I can see, those >> files are now under a cryptic directory name: >> >> fastcomp/3b8cff670e9233a6623563add831647e8689a86b/emscripten/emcc >> >> Before it was something predictable like >> >> emscripten/incoming/emcc >> >> I don't want to "pollute" the global environment with environment or path >> variables (emcc is not in the path for instance), since I want to have >> different SDK versions side by side. >> >> Is there any chance we can have a standardized or "predictable" directory >> structure? Maybe a link to the actual SDK directory with a common name? >> >> Currently that's a bit of a show stopper for further testing since I >> would need to rethink my the entire emscripten integration into my build >> system. >> >> I'm also getting some errors during installation: >> >> Error downloading URL ' >> https://storage.googleapis.com/wasm-llvm/builds/osx/lkgr.json': HTTP >> Error 404: Not Found >> Error parsing lkgr.json! >> [Errno 2] No such file or directory: >> '/Users/floh/projects/fips-sdks/osx/emsdk-portable/upstream/lkgr.json' >> >> Cheers, >> -Floh. >> >> On Friday, 24 May 2019 02:45:05 UTC+2, Alon Zakai wrote: >>> >>> We have been working hard to replace the current build infrastructure >>> with a new system. The new one will be faster, have better support for >>> testing, and support the LLVM wasm backend (in fact this change is the last >>> blocker for us switching to that by default). As of now you can start to >>> test this out, if you do the following: >>> >>> * get latest emsdk master >>> * ./emsdk install latest-releases-fastcomp >>> * ./emsdk activate latest-releases-fastcomp >>> * optionally add the directory to the path with: source ./emsdk_env.sh >>> >>> That will install a new release tag, 1.38.33, from the new builders. >>> >>> Note that there is no change to "latest" (or other modes) - this just >>> adds this new "latest-releases-fastcomp". But after we are sure things work >>> well, the goal is to make "latest-releases-fastcomp" replace "latest". >>> >>> Please let us know if you see any issues with the emsdk or with using >>> emcc from that install! >>> >>> Notes: >>> >>> * You can replace "fastcomp" with "upstream" to use the LLVM wasm >>> backend. We'll have a larger announcement about this soon. >>> * The new builders don't download java yet, so closure compiler won't >>> work (unless you install it yourself). Aside from that, things should work >>> just like "latest". >>> >>> - 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:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/fb29262a-bbad-4a29-b818-1d4ad861a5e1%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/fb29262a-bbad-4a29-b818-1d4ad861a5e1%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/74cb536f-e540-4a18-ab77-53454ba73292%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
