Re:The origins of Objective-C at PPI/Stepstone and its evolu...
by mwcampbell on Sunday June 14, 2020 @01:36PM
(#23519575)
> This is how Gecko is built too—essentially everything ends up in libxul unless it has to be split out so that link.exe doesn't OOM on 32-bit (sadness). I believe it had been this way when the first version of Chrome was released, so this wasn't something Chrome introduced.
Touché. And I do remember seeing this in Firefox, or maybe even the old Mozilla suite, long before Chrome came out.
Still, I think static linking is a much more effective optimization in Chrome, because Chrome doesn't make heavy use of internal ABI boundaries (e.g. COM or XPCOM), so link-time optimization can be more aggressive. IIUC, Firefox and Thunderbird still use a fair amount of XPCOM internally, because they have lots of modules written in JavaScript, including all of the code behind the XUL-based UI. Chrome, on the other hand, uses a lot more C++.
Re:The origins of Objective-C at PPI/Stepstone and its evolu...
by pcwalton on Sunday June 14, 2020 @01:42PM
(#23519618)
Chrome has a lot of the frontend written in JS nowadays too. At this point XPCOM is mostly just a bindings layer between JS and C++ (that's what COM was supposed to be to begin with—a glue layer between languages). V8 has something similar.
I don't think you can really say static linking is more effective in Chrome or Firefox. Both browser architectures are broadly similar these days.
This is how Gecko is built too—essentially everything ends up in libxul unless it has to be split out so that link.exe doesn't OOM on 32-bit (sadness). I believe it had been this way when the first version of Chrome was released, so this wasn't something Chrome introduced.
(Also, based on my experiences with Node and other Google projects like Skia, I wouldn't consider gyp a great build tool—it's always been a nightmare for me. gn is better, but Google projects still have a tendency to be difficult to build for those who aren't Google employees.)