-
Notifications
You must be signed in to change notification settings - Fork 6
2024 Demoing the new WebKit Container SDK
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/31
- Slides: https://notes.igalia.com/p/DQI8U3r7q#/
Patrick presenting the slides & demoing the sdk and vscode.
alexg: when you use vscode, do you still use the script for compiling (e.g. ./Tools/Scripts/build-webkit)
patrick: I do not, you can configure the vscode pref to do that
alexg: patrick you are using a mac. how complex it is to run the new webkit sdk on a mac? patrick: you can use podman. problem is for graphics, and so on that don't work. so you'll have to use a virtual machine, ... not ideal but the best we can do. alexg: not using a container, just installing linux on the mac. niko: the system we use as a base is Ubuntu 23.04. It supports debuginfod , which will automatically download the debug info at source code level when you are debugging.
alex: does clangd work with unified builds, or does it use custom stuff? patrick: we do a lot of custom stuff. but in the end it works.
georges: In the past I used VSCode, and the main pain points were the amount of manual things to make this work. patrick: thinking of having a script to set the config niko: how about using a symlink? patrick: alicia's patch actually does that alicia: want to clarify something. concerns about vscode hard to setup. it actually isn't. the nice thing about the language server protocol, is that it is a protocol. you don't need vscode, you can use clangd with kate, for example. You can run all webkit scripts inside the console, you don't need vscode. nice it about the container: before that, would need to deal with a lot of deps, container makes it easy. cmake as presets that can be understoods by IDEs, that already allows to open the project in VSCode using these presets to be able to build. you can make your own user presets. alexg: isn't it possible to have everything like that in the container already alicia: the presets are already in the webkit repo actually alexg: about the json conf georges mentioned? patrick: we can include settings a user level. since the container isolated, not overriding user settings. we could do that foer sure alicia: this is not ideal though, patrick: thinking of having a script to apply the settings alicia: considering having a json parser to do that, but stopped at the end. could retake that. vitaly: there are 2 different json files. one is cmake presets, makes very easy to use VScode, I only need to open vscode and open the presets. alicia: UI has changed vitaly: I wish I had the same setup as patrick but don't want to spend time. If we share the presets everyone could benefits from them, just need to be careful (don't commit full path for example). alicia: we don't want to have settings in the git repo, as users want to set their own values (e.g. different number of of CPU). vitaly: maybe a minimum set of settings alicia: would be nice. vitaly: settings are in the home directory, you can change at any time. and the committed presets for everyone would be a different file. niko: goal is to have zero configuration. so we would like to have the prefs committed in the repo. how it's in the end implemented I don't know, but that's the spirit of the sdk quique: you can an extension in a different place alicia: yes, but users won't know. quique: yes but I prefer to have a template than nothing and let the users configure the things themselve. claudio: share to everyone sharing things. we really need to fill the gap between having it working and starting from zero. it's fine to have the current things and document the other things that cannot be automated. with my workflow with emacs, not going to spend the day trying to configure. I've starting to use mac and xcode and find it very lacking. from a person coming from a linux background, it's insufficient. we shouldn't fall in the same kind of trap of assuming that people already know what to do. anyway, thanks for the amazing work. alicia: please do file bug report for SDK things that don't work an even if you don't know how to fix it. niko: agree everthing should be document. but want to highlight this (vscode configuration) is the only thing that does not work out-the-box . all the others things (rr, valgrind) work, that's the best out-of-hte-box experiment we have. thanks to your hard work. georges: something else in my mind maybe not a fair thing to talk about. would like to know any way to work around the sdk/container sandbox. one of the use case is accessibillity, was working with flatpak. testing does not exist. after epiphany release, realized nothing worked. can this use case be testable in the sdk. e.g. run epiphany with the build in the sdk patrick: flatpak complicate because of sandboxes. don't really know an easy way. flatpack as all the a11y things? georges: is not fair to mention it, because does not work outside the sdk niko: sdk not extra layer of burden since it actually adds necessary deps alex: What about using a custom build of a browser like epiphany for dogfood? How easy is it? patrick: I have a laucher for epiphany that does wkdev-enter to launch it from inside the container. So it's possible. alex: But where does the configuration and personal data comes from? patrick: From inside the container(?). We try to expose as much portals/services from the host as possible, but some things like the realtime portal does not work. alex: sysprof supported? can you show it? patrick: need some work georges: can use sysprof without a server niko: ask what they are still missing in the sdk. what about something to pack your sdk in the state it is right now and then be able to share it with anyone else. for example to seek help from a colleague alicia: we could probably make something work, on top of the base layer. checking a library at a specific version. could require deciding, niko: I can already do that with podman, would like the same in the sdk niko: I want to have a CI so when there is a bug I have a download button with the current state etc alicia: would need to put a big chunck of the git repo into the image. need to figure out where the container images stored etc patrick: podman has local shares alicia: that reduces the concern
alexg: time for another tool? what about rr? patrick: I haven't used it in the sdk niko: need to have things like perf_event_paranoid settings etc in webdev-setup-debugging ; patrick opens issue #24 for that
alicia: about nvidia and drivers in the container. niko explains
patrick: all I have to share, thank you all.