Would it make sense to have the option of using system/external icu if available, similar to nspr? It doesn't make sense to rebuild icu all the time if it's not going to change.
-David On 04/30/2013 02:07 PM, Jeff Walden wrote: > With bug 866305 landed, the shell build by default now includes the Intl > object, and the existing toLocale*String methods all use Intl functionality > to work. Yay! > > But this also means that building now requires building ICU as well. Not so > yay. That adds several minutes to compile time (for me, with a -j8 build and > some inadvertent ccaching I forgot to turn off), a several-x increase in > overall compile time. > > You should be able to disable the Intl API using --disable-intl-api, to avoid > this compile-time hit. If you're not touching Intl code, you might often be > able to get away with this. In the longer run, however, this probably isn't > sustainable -- particularly as new tests of Intl stuff get landed, and as > fuzzers start fuzzing it. But eh, as long as you don't push bustage, feel > free to disable if you want. :-) > > Note that there's some thought to removing this frob, so that Intl code is > just always there and won't bitrot. I'm not entirely certain what the > thought is on when, exactly, we should do that. Maybe after it's shipped in > a release and we're confident in its being enabled for good. So in the long > run, disabling Intl for faster clobbers isn't going to cut it. I recommend > using ccache with a generous cache size (see |ccache -s| and |ccache -m| to > view and change cache size) to ameliorate this concern. > > Jeff > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
