Re: [webkit-dev] Proposal to enable logging under non-systemd linux distros
On Wed, Oct 20 2021 at 02:07:56 AM +0200, Pablo Correa Gomez via webkit-dev wrote: - Rename USE_SYSTEMD to USE_JOURNALD and have a conditional check which looks for elogind if libsystemd is not found, similar to the hack I used for proof-testing. This one! Do this one! We don't need two different build options for systemd vs. elogind, when all we really care about is whether the journald API is available. Michael P.S. (We might also consider adding an environment variable to redirect all log messages to stderr. This is *almost* possible now after https://trac.webkit.org/changeset/283469/webkit, but requires more playing with the #if guards. Don't worry about this if you're not interested in working on it. I just mention it in case that sounds like your idea of an exciting project. ;) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal to enable logging under non-systemd linux distros
Dear webkit maintainers,
I am a contributor to postmarketos/alpine linux. We recently bumped
into some runtime crashes in webkit2gtk which were very hard to debug
due to the lack of logging. The reason for the lack of logging seems to
be that alpine configures webkit2gtk with -DPORT=GTK -DUSE_SYSTEMD=OFF
and then the USE_JOURNALD macro does not get set.
However, in systems like alpine which do not use systemd, it is common
that a compatible logind, elogind[1], be used. When this is the case,
then the current functions used for logging to systemd's journal are
perfectly compatible. To make sure it works, I have create a small
patch/hack to test it, which compiled in a system with elogind instead
of systemd USE_SYSTEMD=ON:
diff -ru a/Source/cmake/FindSystemd.cmake
b/Source/cmake/FindSystemd.cmake
--- a/Source/cmake/FindSystemd.cmake
+++ b/Source/cmake/FindSystemd.cmake
@@ -68,6 +68,11 @@
HINTS ${PC_SYSTEMD_LIBDIR} ${PC_SYSTEMD_LIBRARY_DIRS}
)
+find_library(Systemd_LIBRARY
+NAMES ${Systemd_NAMES} elogind
+HINTS ${PC_SYSTEMD_LIBDIR} ${PC_SYSTEMD_LIBRARY_DIRS}
+)
+
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Systemd
FOUND_VAR Systemd_FOUND
I would be happy to contribute a decent patch, but as it would modify
the parameters available for distros to configure, I have some doubts
about which would be the best way to proceed. I could see two options:
- Create a new configuration option (USE_ELOGIND), most likely
muplicating most of systemd cmake code.
- Rename USE_SYSTEMD to USE_JOURNALD and have a conditional check
which looks for elogind if libsystemd is not found, similar to the hack
I used for proof-testing.
My question is, which of these two options would be best suitable? If
none of them is, which would be the better way to add the possibility
to configure webkit2gtk using elogind?
Best regards and thank you very much for your time,
Pablo Correa Gómez.
[1] https://github.com/elogind/elogind
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -Wreturn-type and -Wredundant-move reminders
On Tue, Oct 19 2021 at 01:43:19 PM -0700, Ryosuke Niwa wrote: Can we add a style checker rule to detect at least simple cases? I think detecting this pattern without false positives would be pretty tough. Requires too much knowledge of the semantics of the code. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Updating iOS EWS
We are currently updating all embedded EWS hosts to iOS15 aligned releases. Expect delays and offline hosts. We appreciate your patience. Matt Lewis ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -Wreturn-type and -Wredundant-move reminders
On Tue, Oct 19, 2021 at 1:15 PM Michael Catanzaro via webkit-dev <
webkit-dev@lists.webkit.org> wrote:
> A reminder about this common idiom:
>
> switch (...) {
> case Foo:
> return ...;
> case Bar:
> return ...;
> }
> RELEASE_ASSERT_NOT_REACHED();
>
> When it's intended that the code always returns inside the switch
> statement, the RELEASE_ASSERT_NOT_REACHED() is required to avoid
> tripping GCC's -Wreturn-type. If you forget it, I or somebody else will
> wind up adding it later to avoid the warning. Clang does not warn here,
> and this is the most common type of warning I clean up, so please don't
> forget! :) This warning is useful in other situations, and it seems
> nicer to placate GCC than to disable it.
>
> I'll sneak in another reminder: "return WTFMove()" is almost always not
> needed. Clang warns only if the move prevents return value
> optimization, but GCC will always warn if it detects the move is
> unneeded.
>
Can we add a style checker rule to detect at least simple cases?
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] -Wreturn-type and -Wredundant-move reminders
Hi devs,
A reminder about this common idiom:
switch (...) {
case Foo:
return ...;
case Bar:
return ...;
}
RELEASE_ASSERT_NOT_REACHED();
When it's intended that the code always returns inside the switch
statement, the RELEASE_ASSERT_NOT_REACHED() is required to avoid
tripping GCC's -Wreturn-type. If you forget it, I or somebody else will
wind up adding it later to avoid the warning. Clang does not warn here,
and this is the most common type of warning I clean up, so please don't
forget! :) This warning is useful in other situations, and it seems
nicer to placate GCC than to disable it.
I'll sneak in another reminder: "return WTFMove()" is almost always not
needed. Clang warns only if the move prevents return value
optimization, but GCC will always warn if it detects the move is
unneeded.
Have a nice day,
Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for position: WEBRTC-SVC
Le mar. 19 oct. 2021 à 00:24, Harald Alvestrand via webkit-dev < webkit-dev@lists.webkit.org> a écrit : > Chrome is considering releasing an implementation of the WEBRTC-SVC API. > API documentation: https://w3c.github.io/webrtc-svc/ > > This has been available in Chrome behind a flag for some time, and we > believe it is ready for wider availability. > > As part of the process of evaluating whether or not to release this, we > would like to have input from the WebKit community. > Being able to set the SVC mode using https://w3c.github.io/webrtc-svc/#rtcrtpencodingparameters is a very welcome addition. Being able to query the SVC modes should ideally be done using Media Capabilities. Media Capabilities already has support at https://w3c.github.io/media-capabilities/#dom-videoconfiguration-scalabilitymode . I would tend to remove https://w3c.github.io/webrtc-svc/#rtcrtpcodeccapability* from the spec and filed https://github.com/w3c/webrtc-svc/issues/49 to follow-up on this. I hope Chrome can delay its decision to expose RTCRtpCodecCapability.scalabilityModes to allow the W3C WebRTC WG to form a decision on https://github.com/w3c/webrtc-svc/issues/49. > Thank you! > > Harald Alvestrand > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
