Ok, after mucking around for most of the day with cleaning up my build 
system integration I can say: "it works" (the "latest-releases-fastcomp" 
SDK version). I was expecting that the closure pass breaks, but looks like 
it works since I had a Java RTE "accidently" installed). I have only tested 
my sokol-samples so far, but these are quite "representative" I think.

I wrote down some feedback in this PR:

https://github.com/emscripten-core/emsdk/pull/248

Cheers,
-Floh.

On Friday, 24 May 2019 23:44:38 UTC+2, Alon Zakai wrote:
>
> Yeah, that might be useful - I opened 
> https://github.com/emscripten-core/emsdk/pull/247 for further discussion. 
> I also wonder if a fixed dir might be better actually, also mentioned there 
> as a question.
>
> - Alon
>
>
> On Fri, May 24, 2019 at 10:26 AM Floh <[email protected] <javascript:>> 
> wrote:
>
>> > 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]> 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].
>>>> 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] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/emscripten-discuss/74cb536f-e540-4a18-ab77-53454ba73292%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/emscripten-discuss/74cb536f-e540-4a18-ab77-53454ba73292%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/29e1de70-011e-4bc0-814d-be293d332142%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to