[M3commit] CVS Update: cm3

Rodney M. Bates rodney at elego.de
Thu May 9 20:02:45 CEST 2013


CVSROOT:	/usr/cvs
Changes by:	rodney at birch.	13/05/09 20:02:45

Modified files:
	cm3/m3-sys/cminstall/src/config-no-install/: Tag: 
	                                             release_branch_cm3_5_8 
	                                             cm3cfg.common 

Log message:
	Since dinosaurs roamed freely, the cm3 executable is not shipped,
	even if you specify ship or buildship, unless you also set environment
	variable INSTALL_CM3_IN_BIN="yes".  This avoids:
	
	1) Undermining an executing executable, which won't work on some OSs, and
	
	2) Changing compilers in the middle of group of builds.  Everything can be
	built with the same, prexisting compiler, including the compiler. This
	is sometimes essential to avoid bootstrapping barriers, etc.
	
	A built but not shipped compiler can be installed later, using
	scripts/install-cm3-compiler.sh.
	
	Item 2) above is also relevant to cm3cg as well.  We currently have an apparent
	bootstrap barrier where both cm3 and cm3cg need to be updated to the head
	atomically.  As is, a new cm3cg is built and installed in /usr/local/cm3/bin,
	while the old cm3 remains.  If that is the release cm3, every following M3
	compilation suffers:
	
	m3cgc1: fatal error:  *** illegal type: 0x17, at m3cg_lineno 4
	
	The change to m3-sys/m3cc/src/m3makefile in the *HEAD* is one part of the fix.
	It makes installing of cm3cg work like cm3.
	
	The change to m3-sys/cminstall/src/config-no-install/cm3cfgt.common in the
	*RELEASE* is the other part.  Currently, the release searches all over much
	of the known universe for a cm3cg/m3cgc1, and will pick up even an uninstalled
	one in preference to the installed version, creating the same problem.  This
	seems very difficult to fix without changing the release branch.




More information about the M3commit mailing list