67979 2011-09-12 18:55:24 -0700 REGRESSION(94981): Non-JavaScriptCore builds cannot compile without compiling runtime/UString.cpp 2011-09-13 01:27:59 -0700 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 1 webkit.review.bot webkit.review.bot ap barraclough fishd ggaren jamesr msaboff oldest_to_newest 466024 0 webkit.review.bot 2011-09-12 18:55:24 -0700 REGRESSION(94981): Non-JavaScriptCore builds cannot compile without compiling runtime/UString.cpp Requested by jamesr_ on #webkit. 466028 1 jamesr 2011-09-12 18:59:05 -0700 http://trac.webkit.org/changeset/94981 added a caller to UString::latin1() in YarrInterpreter.cpp. UString::latin1() is defined in runtime/UString.cpp, as opposed to most UString functions which are defined in UString.h. This creates a new build time dependency on runtime/ from yarr/ which didn't previously exist. For ports that build (or can build) without JSC this is a bit tricky to resolve, since compiling UString.cpp requires building the rest of runtime/ and (it seems from a brief inspection) most of the rest of JSC. One fix would be to use the wtf/text/ string types instead of JSC::UString inside of YARR. Another option would be to put the definition of latin1() in UString.h. What is the expected dependency graph here between runtime/, wtf/ and yarr/? See http://trac.webkit.org/changeset/94997 466038 2 jamesr 2011-09-12 19:20:49 -0700 WTF::String has a latin1() that looks identical to UString's. Would it make sense for CharAccess be implemented in terms of WTF::String or WTF::StringImpl instead of JSC::Ustring? 466150 3 ap 2011-09-12 23:03:44 -0700 This shouldn't have resulted in a rollout. Non-JSC builds are not required to be maintained by core developers - this was a condition for admitting those in trunk. 466151 4 ap 2011-09-12 23:04:57 -0700 Sorry, I had absolutely no reason to complain - looks like there was no rollout. My apologies. 466188 5 barraclough 2011-09-13 01:27:59 -0700 > What is the expected dependency graph here between runtime/, wtf/ and yarr/? yarr is dependent on much of the rest of JSC. e.g. yarr has a JIT and as such makes use of JSC assemblers classes. Personally I would be interesting in making yarr depend solely on wtf, but this would mean moving the JIT code generation infrastructure into wtf, and I'm not sure if I'd find support for that idea. :-) > WTF::String has a latin1() that looks identical to UString's. Would it make sense for CharAccess be implemented in terms of WTF::String or WTF::StringImpl instead of JSC::Ustring? Yep, it should be possible to make this be in terms of StringImpl (or WTF::String, but StringImpl is used broadly throughout JSC & WTF::String isn't currently). In the longer term, the plan is for UString to go away (we very nearly finished unifying UString & String some time back, but didn't quite get there), but CharAccess is a temporary class (a part of the process of introducing 8-bit string support to StringImpl), and CharAccess would likely be replaced by something that worked in terms of StringImpls or Strings anyway.