The short answer is that worrying about changes to changes to the installer vs. the runtime is like the difference between a booster rocket and the command module in the Apollo missions: the former is discarded after getting you off the ground, whereas the latter has to get three people safely to the moon and back. That's doesn't make changes to the former trivial, but there's a different order of magnitude of "heavyweight" if you're changing the latter.
The change to nsinstall.c looks to be about twenty lines, and I was going to dummy out changing the new "do" variable in the options parsing and the contents of the functions that does the work if DARWIN isn't defined. This isn't any more code added than the workarounds for something like platforms that don't have fchmod(), and the result is that all other platforms get a new null options in a tool used solely for installation rather than any changes to code in the runtime, where the changes to the Makefiles should in any case limit option use to adding it in Darwin.mk. (IOW: for all other platforms, you'd have an option that isn't invoked, that would be ignored if it weren't, and wouldn't do anything if it were, meaning the code's there but completely inert on other platforms.) I'd very much prefer to limit changes to installer tooling, partly because the changes are so easy to verify (e.g. compare "make -n" output for all build steps before and after on Darwin and a non-Darwin clean build, compare checksums of the resulting files in the build tree to make sure you're lipo'ing unspoiled ingredients, and run the test suite against the resulting fat binaries under "arch" for each platform just to be that the resulting binaries haven't been bitten by a radioactive spider or exposed to gamma radiation) compared to, say, making sure that a change to the DPRG doesn't break FIPS compliance or hit some corner case in compiler behaviour on one of the platforms not covered by the tinderboxen. In this sense, code changes to the installer really don't amount to much if they don't have any further impact on what's being installed. All of which is to say that these changes, while not utterly trivial, can be readily scoped, contained, and verified. So I'm not arguing with your remark about this being a considerable change, just saying that it looks pretty manageable going in and relatively minor compared to touching anything else ending in .c or .h. I've gotten the changes largely ready in the time it's taken to discuss this, so I'm happy to start providing patches at this point. Now, as for the hack you've suggested, it's interesting, but it's not great from a maintainability perspective. Instead of something like a recursive make that then iterates running through each of the platforms and letting the Makefiles decide what the defines should be, you take the derived defines and paste them into -Xarch settings and use a dummy target. It's not a huge problem, as the arch-specific defines aren't likely to change that much, if at all, but it's still got a degree of inherent fragility because of how it's hacked against the grain. Issues like Apple removing support for PPC in Xcode shows that there are also times when external changes would break this, so you can't just hit and run, which returns to a basic question of maintainability. It's still fundamentally viable, but I think the relative virtue of what I've cooked up is that it's a one-time change that I've made as consistent as possible with how things already work, which assumes that one make invocation targets one platform. Working with that premise still means you have to iterate through the builds for everything you want rolled into the installed binaries, but, hey, that's what macports is for. As for which is more suitable, we've both had a chance to make our cases, so I think we should get some feedback from others in the community. On 27 Mar 2011, at 09:23, Kaspar Brand wrote: > On 26.3.11 13:13, Bayard Bell wrote: >> I don't see what's so preferable about marginally optimising the >> mechanics of this on OS X if it looks to make far more fundamental >> changes in the code and the build process that do not fundamentally >> jibe with their apparent design philosophy. Why would it be so >> preferable to use gcc than lipo in the first place, given that the >> former appears to be a more disruptive approach? > > Well, patching nsinstall.c etc. to deal with lipo (as suggested in your > earlier post) seems like a pretty heavyweight modification to me. > > See the follow-up I just posted to the "Problems Building NSS on Mac OS > X 10.6 (64-bit)" thread for a more suitable solution. > > Kaspar > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto
PGP.sig
Description: This is a digitally signed message part
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
