Bug 72152 - Rename JavaScriptCore/wtf/unicode/UTF8.{cpp, h} to JavaScriptCore/wtf/unicode/WTFUTF8.{cpp, h}
Summary: Rename JavaScriptCore/wtf/unicode/UTF8.{cpp, h} to JavaScriptCore/wtf/unicode...
Status: RESOLVED DUPLICATE of bug 70913
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-11 10:48 PST by Daniel Bates
Modified: 2011-11-11 11:13 PST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Bates 2011-11-11 10:48:34 PST
When building using CMake with ICU enabled on a default installation of Mac OS 10.6.8, with a case-insensitive HFS+ formatted hard drive, JavaScriptCore/wtf/unicode/UTF8.h gets included from the ICU header utf.h. But the ICU header utf8.h should be included instead of JavaScriptCore/wtf/unicode/UTF8.h. One idea to avoid this naming collision is to rename JavaScriptCore/wtf/unicode/UTF8.h to, say, JavaScriptCore/wtf/unicode/WTFUTF8.h. I'm not very happy with this idea and would greatly appreciate any insight/suggestions into how to resolve this issue.

I tried changing the CMake build system so that it uses the ICU headers in JavaScriptCore/icu and WebCore/icu when building JavaScriptCore and WebCore, respectively, but the same issue persists. That is, when JavaScriptCore/icu/unicode/utf.h includes utf8.h it includes JavaScriptCore/wtf/unicode/UTF8.h instead of JavaScriptCore/icu/unicode/utf8.h.

From briefly looking at the xcodebuild output of the Apple Mac build I noticed that it includes -I. and -Iicu among the include directories. I also tried a similar approach to no avail.

Additional remarks:

Inserting a #pragma message directive to more easily see this issue and compiling Source/WebCore/platform/text/TextCodecUTF8.cpp, I get the following output:

...
[ 29%] In file included from /Users/dbates/Desktop/RIM/staging/usr/include/unicode/utf.h:230,
                 from /Users/dbates/Desktop/RIM/staging/usr/include/unicode/utypes.h:37,
                 from /Users/dbates/Desktop/RIM/staging/usr/include/unicode/uchar.h:26,
                 from /Users/dbates/Desktop/RIM/webkit/Source/JavaScriptCore/wtf/unicode/icu/UnicodeIcu.h:27,
                 from /Users/dbates/Desktop/RIM/webkit/Source/JavaScriptCore/wtf/unicode/Unicode.h:31,
                 from /Users/dbates/Desktop/RIM/webkit/Source/WebCore/platform/text/TextCodec.h:35,
                 from /Users/dbates/Desktop/RIM/webkit/Source/WebCore/platform/text/TextCodecUserDefined.h:29,
                 from /Users/dbates/Desktop/RIM/webkit/Source/WebCore/platform/text/TextCodecUserDefined.cpp:27:
/Users/dbates/Desktop/RIM/webkit/Source/JavaScriptCore/wtf/unicode/utf8.h:30: note: #pragma message: JavaScriptCore/wtf/unicode/UTF8.h
Building CXX object WebCore/CMakeFiles/webcore.dir/platform/text/transcoder/FontTranscoder.cpp.o
In file included from /Users/dbates/Desktop/RIM/webkit/Source/WebCore/platform/text/TextCodecUTF8.cpp:27:
/Users/dbates/Desktop/RIM/webkit/Source/WebCore/platform/text/TextCodecUTF8.h:50: error: 'U8_MAX_LENGTH' was not declared in this scope
...

The directory /Users/dbates/Desktop/RIM/staging/usr/include is specified to g++ using -isystem so that it is included in the system header search path.

Both RIM/staging/usr/include/unicode/utf.h and JavaScriptCore/icu/unicode/utf.h include utf8.h as follows:

/* include the utfXX.h ------------------------------------------------------ */

#include "unicode/utf8.h"
#include "unicode/utf16.h"

(http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/icu/unicode/utf.h?rev=74855#L215)

Notice the use of a relative include path. Changing "unicode/utf8.h" to "utf8.h" above resolves the build issue but it's undesirable to change these ICU headers as they are from a third-party.
Comment 1 Raphael Kubo da Costa (:rakuco) 2011-11-11 11:11:04 PST
This looks like bug 70913.
Comment 2 Daniel Bates 2011-11-11 11:13:40 PST

*** This bug has been marked as a duplicate of bug 70913 ***