Bart Smaalders wrote: > We've worked very hard to make this work for ON; getting everyone to > remove __DATE__ and __TIME__ macros from their source code everywhere > is hard. Also, compilers love to leave notes about stuff as well.
Yes, I'm painfully aware of the issues. (Those compiler notes... speaking of sections randomly added to the file and delivered to customers...) Particularly bad are the C++ compilers that apparently generate some of their internal symbols randomly. (Note that __DATE__, __TIME__, those C++ symbols, and jar timestamps will all still look like "real" differences to you.) > One of the things we said we were NOT going to do is mandate a build system > for everyone. Getting all file generation to be deterministic seems > like a tall order. Indeed. The question is whether breaking the assumption that two installations of the same version of a package will have bit-for-bit identical files is acceptable. I'd personally say "no", that it's a reasonable and valuable assumption and that breaking it is likely to cost more than any savings. (Remember that service calls start at about $25 each just to say "hello", and you can move an awful lot of bits for $25.) If you really must optimize out the "unimportant" changes, I'd recommend pushing it as far "upstream" as possible, to minimize the number of people who see two packages with different files in them. The stuff I'm saying about comparing systems isn't a thought experiment; people do that kind of thing all the time. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
