Add a #include <pal/Logging.h> to a .cpp file can break the build, because subsequent files in the same UnifiedSources*.cpp may use the LOG macro, and pal/Logging.h and Logging.h #define LOG_CHANNEL_PREFIX to different things.
I don't think pal/Logging.h should define any log channels, nor define LOG_CHANNEL_PREFIX.
Errors look like:
Undefined symbols for architecture x86_64:
"WebCore::PALLogIndexedDB", referenced from:
WebCore::injectIDBKeyIntoScriptValue(JSC::ExecState&, WebCore::IDBKeyData const&, JSC::JSValue, WTF::Variant<WTF::String, WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow, 16ul> > const&) in UnifiedSource170.o
"WebCore::PALLogStorageAPI", referenced from:
WebCore::canInjectIDBKeyIntoScriptValue(JSC::ExecState&, JSC::JSValue const&, WTF::Variant<WTF::String, WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow, 16ul> > const&) in UnifiedSource170.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I think we can just gut pal/Logging.h
Might we want to move commonality up to WTF then specialize based on WebCore/PAL etc?
Yes, we should.
Created attachment 341941 [details]
Comment on attachment 341941 [details]
Clearing flags on attachment: 341941
Committed r232550: <https://trac.webkit.org/changeset/232550>
All reviewed patches have been landed. Closing bug.