http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #18 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-10 20:41:15 UTC --- (In reply to comment #16) >>> So t-multilib is autogenerated in the source tree during the build??? >> >> Jepp. Top $(srcdir)/gcc/config/avr/t-multilib reads: >> >> >> # Auto-generated Makefile Snip >> # Generated by : ./gcc/config/avr/genmultilib.awk >> # Generated from : ./gcc/config/avr/avr-mcus.def >> # Used by : tmake_file from Makefile and genmultilib > > But this is a no-no, the compiler should be buildable with read-only sources > once it is packaged in the release tarballs. It works with read-only sources, provided everything is consistent. Or are you saying that a t-snip must not use $(STAMP)? Actually, the PR boils down to the fact the STAMP is not defined, I am nut sure if the compiler is supposed to build without STAMP. >> Rationale is that avr-gcc supports an, IMHO, insane number of >> -mmcu=<device>. >> In order to keep various parts of the compiler in sync, some bits are >> auto-generated, amongst them documentation, t-multilib and .opt parts. >> >> Procedure is a move-if-change scheme, i.e. the auto-generated files are in >> the >> repository and the procedure to build them is similar to building configure >> from configure.ac and then putting both configure.ac /and/ configure into the >> repo. > > Building configure from configure.c isn't done at build time. > > Either you generate t-multilib like configure and you can put it in $(srcdir) > or you generate it at build time and you must put it in $(builddir). Is basically follows an idea introduced with genopt.sh in http://gcc.gnu.org/viewcvs?view=revision&revision=175248 Notice how t-avr builds avr-tables.opt, and that the latter is added to the repo.
