Conference smurf::buildhelp

257.0. "Q: Build question about 1 output flavor for the kit and 1 flavor for building other pieces" by SMURF::FILTER (Automatic Posting Software - mail to flume::puck) Wed Aug 04 1993 16:57

Date Of Receipt: 	 4-AUG-1993 15:46:41.91
From: 	QUARRY::"[email protected]"
To: 	quarry::buildhelp
CC: 	burgess@DEC:.zko.quarry
Subj: 	Q:  Build question about 1 output flavor for the kit and 1 flavor for building other pieces
------------Mail item #2129-------------------------4-AUG-1993 12: 	08:33.89--------

Here's my agosminor build problem with the Common Agent
	Building some of the common agent components
	(internet_mom, fddi_mom, mir_dat) requires the use
	of some other CA tools/components (mtu, mirc, momgen)
	which also use common agent libraries (libmoss.a ...)

	Currently the makefile for the internet_mom uses
	the newly built mtu image (which also gets installed).
	On 7/30 setjmp.c (libc.a) changed for agosminor
	and the new mtu binary now does not execute successfully on the V1.2 build machine.
	(backwards binary compatibility problem/my illusion)
	
	This is a general problem that can occur when the host 
	machine is running an earlier os version which does not support the newly built
	component.  

Possible Makefile solutions:
	1) Brett suggested linking the CA executables with -called_shared as opposed to -non_shared
           	Will this simple, low-risk solution be sufficient for GOLD? for the long-term?
			Building CA will always require that the "system features"
			used by CA tools and libraries be supported by the build-host machine.

	2) Change the Makefiles to build and use "installable pieces" and "host executable pieces"
	   This change has a broad impact for CA:
		3 makefiles which depend on execution of CA tools (internet_mom, fddi_mom, mir_dat)
		3 makefiles which produce both "installable pieces" and "host executable pieces"
			(mtu, mirc, and momgen(host-exec only))
		o 1-3 CA libraries (/usr/ccs/lib/libmoss, libmoi, libmir)


		a) "vpath method":  
			to build the host-executable pieces, have a subordinate
			makefile and sub-directory which uses vpath to reference
			the .c and .h files in the directory which builds the "installable piece"
			and uses CC_TYPE=host to force the building of a host-executable piece

			to build the dependent pieces(internet_mom, fddi_mom, mir_dat)
			change their Makefile references to use the host-executable pieces.

		b) "all in one makefile method"
			follow the examples of others which use CCTYPE=host
			which produce both "installable pieces" and "host executable pieces"
			in one makefile.

			Unfortunately, I don't wield the power of ode make sufficiently
			to perform this simply:  My brute force method is 
			1) for each .c file have a dependency rule to ${CP} foo.c foo_host.c
			2) foo_host.o_CCTYPE=host
			3) foo_image_OFILES = foo.o ...
	                   foo_image_host_OFILES = foo_host.o ...

			This method involves lots of changes to lots of makefiles...

	My inclination is to due #1 for bl5, and if #1 is not a longer term fix then
	to do 2a in the bl6 time period to eliminate any long term problems.

	Comments?

\Pete Burgess


From:	ALPHA::"[email protected]" "Michael D. Fairbrother UEG  04-Aug-1993 1235"
To:	burgess@dec:.lkg.took     (Even if you're on the right track, you'll get run over if you just sit     there)
CC:	quarry::mdf, abyss::walker
Subj:	Re: I: agosminor build question  


I gone to have to think about this... but here's a couple of thoughts


	o  Brett's option will work, however it chips away
	   at the concept of being able to build for multiple 
	   archiectures both native and cross-development.

	o  I would personaly opt for a solution that makes use
	   of the various passes of the build.  There's 6 phases
	   of the build, it should be possible to set this up
	   to provide a long term and a "correct" solution.


There used to be a "setup" phase of the build.  This however
no longer exists, somehow someone got the idea that it was only
needed for the compilers (not so).  Its main purpose was to build
tools that had to run on the native machine to be used durring the
build process.  This is way out of the scope of Sterling, but maybe
someone could push the Gold team to bring it back.

You also might wish to post this to buildhelp alias to get a 
wider opinion.  Jim McGinness has a very good understand of this
area as well.