I think I've made some progress with the universal build. I managed to build a fat Chromium binary using Xcode and I'll begin submitting the required patches for code review. While the generated xcode projects work well and produce a universal binary as intended, I'm not sure that my approach is entirely clean. As such, I'd like to describe the changes that I've made and, maybe, you could give me some suggestions.
1. Use 'mac_universal' as a target_arch condition. Generating the .xcodeproj can be done with GYP_DEFINES='target_arch="mac_universal" build/gyp_chromium;
2. Enable xcode_settings: ARCHS: $(ARCHS_STANDARD_32_64_BIT) from build/common.gypi. This condition makes XCode build each target twice and obtain a universal binary using lipo.
3. Replace gyp 'defines' entries enclosed in target_arch=<ia32/x64> conditions with GCC_PREPROCESSOR_DEFINITIONS[arch=<i386/x86_64>]. This works surprisingly well provided that a current bug in gyp is fixed first(https://codereview.chromium.org/12094059/
4. Add 'mac_universal' as a valid match for conditions that match both i386 and x86_64. 'target_arch=="ia32" or target_arch=="x64" or target_arch=="mac_universal"' looks rather ugly - maybe gyp can be improved to perform a smarter matching?
With these changes, targets with C/C++/ObjC code should build without any errors. One limitation from which XCode currently suffers, afaik, is that you cannot specify different sets of sources for each target_arch. This means that each source is compiled twice regardless if it is actually used on architecture you're building. The only solution I've found to this is using preprocessor conditions for excluding/including code.
The ugly part: third_party targets which use .asm sources.
Third party dependencies such as libvpx, ffmpeg and libjpeg_turbo use hand compiled .asm sources.
5. Modify the yasm_compile build rule to build each .asm source twice and merge the two objects into one using lipo.
6. The new build rule uses yasm_flags_ia32 and yasm_flags_x64. Therefore, break yasm_flags entries into specialized entries.
Note: XCode links correctly against fat objects.
The downside: you don't have two separate sets of sources and the effects are more visible here: there are a lot of asm sources that should be built for only one architecture. I used preprocessor conditions to fix this, but I don't believe that this is the right way.
7. The assembled objects are parsed/extracted with some custom rules for generating unpacked libs or lists of integer offsets. These rules need to be modified to work with fat objects. These include gen_asm_offets and unpack_lib.
8. Build fat Chromium for greater glory.
I have not tested the ninja build, but I believe that the ninja generator should parse ARCHS and do something similar to XCode.
The IPCs between the main process in 64-bit mode and a helper process in 32-bit mode don't work, which was expected.
Any suggestion is greatly appreciated.