Open Bug 979259 Opened 11 years ago Updated 2 years ago

Touching build/autoconf/icu.m4 doesn't cause ICU to be rebuilt

Categories

(Firefox Build System :: General, defect)

x86
macOS
defect

Tracking

(Not tracked)

People

(Reporter: ehsan.akhgari, Unassigned)

Details

It does cause configure to re-run but I just verified that ICU is not rebuilt as a result.
If it's about bug 978784, then that's expected. That change shouldn't affect how icu is built.
(In reply to comment #1) > If it's about bug 978784, then that's expected. That change shouldn't affect > how icu is built. Changing the arguments passed to the ICU configure script should *definitely* cause ICU to be rebuilt, which is why I filed this bug.
The patch that landed in the end doesn't change arguments passed to ICU configure. The patch that landed first did. The ICU configure ran, and ICU build system was traversed. Which means, sadly, this is an ICU upstream build system issue (one more). Not sure what we should do about this...
(In reply to comment #3) > The patch that landed in the end doesn't change arguments passed to ICU > configure. Oh, right. Yeah sorry I forgot to take that out. > The patch that landed first did. The ICU configure ran, and ICU build system > was traversed. Which means, sadly, this is an ICU upstream build system issue > (one more). Not sure what we should do about this... I tested this locally on Windows, ICU was not rebuilt when I applied the old patch in that bug to an old tree. Note that there is a slight chance that I'm mistaken about that claim though, I did so many rebuilds of that patch last night that it's hard to remember exactly now. Also, FTR, ICU recommends against running their build system when integrating ICU with a medium to large project. I know that I've been unable to convince you about this in the past but FTR, one great way to fix this bug is follow their advice and integrate ICU into our build system. That will fix so many of our problems, and only require a bit of more work for ICU updates, which is already quite painful as Jeff Walden can attest.
Have you ever looked at what an ICU build does? If you were a build peer, or Waldo, would you feel comfortable maintaining that up-to-date with new versions of ICU?
(In reply to comment #5) > Have you ever looked at what an ICU build does? If you were a build peer, or > Waldo, would you feel comfortable maintaining that up-to-date with new versions > of ICU? I admit that I haven't, but I also don't really know anything about the craziness of its build system, so it's hard to make up my mind... Do you know for example why ICU recommends importing their code into other build systems when it's not practical to do so? Note that I'm just asking out of curiosity, and if you don't have time to explain it, no big deal -- I probably won't be touching ICU again any time soon. :-)
The ICU upstream recommendations are awesome: "At least for initial bring-up, use pre-built data files from the ICU download or from a normally-built ICU. Copy the icudtXXx.dat file from icu/source/data/in/ or icu/source/data/out/tmp/ in either of these two locations, into icu/source/data/in/ on your target ICU system. That way, you won't need to build ICU's data-generation tools."
Note that building icu with our build system would, OTOH, solve many of the problems that come with icu's build system.
Product: Core → Firefox Build System
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.