ICU 52 : update gyp and isolate

Update gyp and isolate files for ICU 52.1

Update icu.gyp and related files to list C/C++ source files and header files.

Besides, HAVE_DLOPEN is set to 0 explicitly in icu.gyp. It's 0 by default
in ICU 4.6.1 but is 1 by default in ICU 52.1, but we don't need it. (it's only
necessary for ICU plugins that Chromium does not use).

I also applied https://codereview.chromium.org/218153002/ (Nico's CL to
simplify icu.gyp).

BUG=132145
TEST=None
R=mark@chromium.org, thakis@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=260941

[jungshik at Google, 2014-03-27 11:08:35]

Can you take a look? Thanks.


BTW, I plan to remove / revise entries in README.chromium as I apply local
changes to the clean copy of ICU 52. This is part 1.

[jungshik at Google, 2014-03-28 11:24:41]

I realize that it's hard to tell what's going on and whether dropping them is ok
without patches removed in the CL. Even with them, it may not be easy. Anyway,
if you want to see patches removed in the CL, I can copy them over to icu52 and
land them before this CL [1]. That way, I can include them here as files to
delete.

BTW, I also include icu.gyp and friends here. All but one change are trivial
because they're just updating the source file list. One substantial change is
adding '-ldl'. For a reason unclear to me, v8.mksnapshot complains about dlopen
and friends when linking against libicuuc. (With icu46, it didn't complain). 



[1] After updating to ICU 52.1, I'll talk to the build infra team about setting
a git repository (without the corresponding svn repo) for ICU and consider
'in-place' upgrade. 


[1]

[jungshik at Google, 2014-03-28 11:28:36]

https://codereview.chromium.org/212623010/diff/40001/icu52/icu.gyp
File icu52/icu.gyp (left):

https://codereview.chromium.org/212623010/diff/40001/icu52/icu.gyp#oldcode202
icu52/icu.gyp:202: '-Wno-header-hygiene',
This is another slightly non-trivial change. The upstream fixed this issue and
we don't need this option any more.

[jungshik at Google, 2014-04-01 07:30:46]

On 2014/03/28 11:28:36, Jungshik Shin wrote:
> https://codereview.chromium.org/212623010/diff/40001/icu52/icu.gyp
> File icu52/icu.gyp (left):
> 
> https://codereview.chromium.org/212623010/diff/40001/icu52/icu.gyp#oldcode202
> icu52/icu.gyp:202: '-Wno-header-hygiene',
> This is another slightly non-trivial change. The upstream fixed this issue and
> we don't need this option any more.

I'll change this CL to deal exclusively with gyp* and isolate files and upload
an updated version today. 

I'm almost done with applying local changes necessary for ICU 52.1 (most of
patches to ICU 4.6.1 have been added to the upstream or become obsolete) in my
local tree. I'll make a separate CL for all the local changes I made (except for
one or two changes to trim the data size further down).

[jungshik at Google, 2014-04-01 16:38:46]

PS 4 has only gyp* files and isolate files.

[Mark Mentovai, 2014-04-01 17:04:03]

LGTM. Would it be sensible to not have the ICU version number be part of the
source file? (I may have asked this during some previous ICU update.)

[Nico, 2014-04-01 17:59:51]

Thanks for merging in my cl :-)

https://codereview.chromium.org/212623010/diff/60001/icu52/icu.gyp
File icu52/icu.gyp (right):

https://codereview.chromium.org/212623010/diff/60001/icu52/icu.gyp#newcode288
icu52/icu.gyp:288: # v8 mksnapshot needs dlopen and friends.
This is needed because icu/source/common/putil.c calls dlopen, not becuse
mksnapshot needs it, right? (In the latter case, mksnapshot's project should
have this setting instead.)

(Building icu without HAVE_DLOPEN defined would probably remove icu's calls to
dlopen; I don't know if that would remove important functionality though.)

[jungshik at Google, 2014-04-01 18:22:01]

On 2014/04/01 17:04:03, Mark Mentovai wrote:
> LGTM. Would it be sensible to not have the ICU version number be part of the
> source file? (I may have asked this during some previous ICU update.)

Yes, I want to just use 'icu' instead of 'icuxx'. When I started upgrade to
icu52, I was not sure how long it'll take and  I wanted to avoid a situation
where an urgent security patch has to be applied to the version (currently
pulled in via DEPS) while I'm in the middle of a series of CLs to update. 

 I guess a proper way to deal with this situation is to use a branch.  What I've
done is kinda poor man's branching. 

Alternatively, I can apply all the changes/local patches in as few CLs as
possible (one CL would be ideal ) as we do with other third party libraries.  In
this round, I found that it's almost possible (when I started, I wasn't sure)
and I expect it to be the case down the road as long as I update ICU frequently
(every 6 months or so).   

The downside with this is that we still have a problem if there's a security
patch to apply to the release branch with a different version of ICU.  Maybe, if
we ever come across that situation, we can make a release branch. 

Anyway, if you don't mind, I like to go ahead with icu52 this time and come up
with a better approach next time.

[Mark Mentovai, 2014-04-01 18:24:16]

OK, I didn’t mean for you to change it in this patch. Go with icu52 for now and
put it on whatever rainy-day TODO list you have to rename the data file. It
doesn’t have to coincide with an ICU upgrade, and it will barely complicate
release management (and in the long run, will simplify much more than it will
complicate once-only).

[jungshik at Google, 2014-04-01 20:26:22]

On 2014/04/01 18:24:16, Mark Mentovai wrote:
> OK, I didn’t mean for you to change it in this patch. Go with icu52 for now
and
> put it on whatever rainy-day TODO list you have to rename the data file. It
> doesn’t have to coincide with an ICU upgrade, and it will barely complicate
> release management (and in the long run, will simplify much more than it will
> complicate once-only).

Oh. you're talking about the assembly file name. I misunderstood that you meant
the directory ( deps/third_party/icu52 vs deps/third_party/icu) and wrote about
it in my reply. 

Changing the assembly file name should be simpler, but I'll put off even that
for now because I want to upgrade asap. BTW, as you know, 'icudtl.dat'  (that we
use by default except for Android webview build on Linux/Mac) does not have a
version number any more. 

Thanks for the clarification, though. 

@Nico, thank you for the catch. You're right that ICU 46 didn't define
HAVE_DLOPEN (or set it to 0) while ICU 52.1 sets it to 1 by default. We don't
need that and I set it to 0 in icu.gyp. (see the updated CL description)

Mark and Nico, can you take another look?

[Nico, 2014-04-01 20:31:11]

Patch set 5 lgtm. Thanks!

[Mark Mentovai, 2014-04-01 20:33:08]

LGTM too

[jungshik at Google, 2014-04-01 20:51:49]

Committed patchset #5 manually as r260941 (presubmit successful).