I've attached an answer from the C++ compiler team lead. I don't think it's much help.
All I can think of is wrapping the compiler driver with a script that LD_PRELOADs an interposer on gettimeofday() (or whatever the appropriate libc call is). You know. The usual hack. But maybe sed scripts are easier. It certainly seems like a good RFE if you're interested in a more long-term solution. --chris Bart Smaalders wrote: > <repeated query from tools-discuss> > > W/ gcc, I can overload __TIME__ and __DATE__ & disable warnings > w/ -Wno-builtin-macro-redefined; this allows me to build the same > source multiple times and produce the same binaries, a valuable > means of reducing meaningless downloads for customers. > > This doesn't work w/ the Studio compiler AFAICT. > > Any ideas? I really don't want to run sed scripts over tarballs > on every build to get rid of this problem. > > - Bart > Steve Clamage wrote: > The C and C++ standards say that those macros are predefined by the > compiler, have a constant value that does not change during the > compilation, and user code is not allowed to modify them. Our > compilers follow that rule. > > Someone could file an RFE asking for the rule to be relaxed. We could > downgrade the error to a warning, and the normal message-suppressing > options would eliminate the warning. We would still be in violation of > of the "constant value" provision, so I think modifiability would have > to be controlled by an option. > > My primary concern is that the the effects of modifying __DATE__ or > __TIME__ could be unpredictable. For example, suppose the time and > date data were emitted into the object file dwarf data before the > redefinition are seen. > > Putting the definition on the compiler command line > cc -DDATE='"June 5, 2009"' -D__TIME__='"13:00:00"' > probably could be arranged to work. Macros definitions in the source > code might result in multiple ideas of the compilation date and time. > > --- > Steve Clamage, stephen.clamage at sun.com
