jjo@calmasd.GE.COM (Jay Olson) (10/27/87)
We have an environment which I am sure is becoming quite common these days: a network with a variety of Suns, Vaxen and other assorted machines, many of which run NFS and can see filesystems on other machines in the network. Right now, the X11 source is NFS mounted so that both the Suns and the Vaxen can access it. However, it is somewhat inconvenient to actually build and install X for both types of machines using the same source. If I have built one particular version (say the Sun), and wish to make a small change to the other (say the Vax), I have to make clean, possibly fiddle with some files, remake the makefiles, remake the dependencies, and completely remake X. Needless to say, this is quite time-consuming. Has anybody else faced a similar situation? Can anybody suggest a viable alternative? Is it possible to change some of the Imake rules so that the resulting makefiles put the objects in different places? Any hints or suggestions would be appreciated. Jay Olson a consultant working at GE Calma San Diego, CA jjo@calmasd.GE.COM ...sdcsvax!calmasd!jjo
wohler@milk1.istc.sri.com..istc.sri.com (Bill Wohler) (10/28/87)
Jay Olson writes: >However, it is somewhat inconvenient to actually build and install X for >both types of machines using the same source. If I have built one particular >version (say the Sun), and wish to make a small change to the other (say >the Vax), I have to make clean, possibly fiddle with some files, remake the >makefiles, remake the dependencies, and completely remake X. Needless to >say, this is quite time-consuming. this is another case of your space vs. time tradeoff. we use a set of sources for each architecture we have here. i've chosen one machine to house the "master" sources--it is here where patches and new software is added. i then rdist the sources to the other machines that have the sources. i use judicious use of the except_pat function in rdist so that .o, RCS, and other files are not transported. after rdisting the software to the other machines, i'll run a "make install" on those machines. since rdist has only updated the new sources, only the new sources get recompiled. after compilation, i make a "binary distribution" by rdisting the sources and libraries only from the source machines to other similar machines that don't NFS mount the source machine's /usr/new (in our case). actually, i could also make use of the rdist "special" command to run the remote make install and binary distribution. --bw disclaimer: i can't mail out my Distfile because it doesn't exist yet. ;-) i currently do this stuff with gnuemacs--X will be a simple extension.
joel@pyr.gatech.EDU (Joel Rives) (10/28/87)
There is no need to rewrite the rules for 'make' to do what you are seeking to do. First, it is only necissary to remove object files which will be using an include file that has been altered. Secondly, it is possible to have entries in your 'Makefile' -- one for each system that you wish to rebuild 'X' for such that it saves and retrieves the appropriate object files from specific subdirectories. Here's an exmaple that I have just thrown together of the top of my head. There is probably a more efficient way to do this but it shows the general idea. # # Makefile example # CFLAGS = -g OBJS = ( list of object files) vax: setvax $(OBJDIR)/$(OBJS) cc $(CFLAGS) -o X $(OBJDIR)/$(OBJS) setvax: vaxobj/$(OBJS) OBJDIR = vaxobj sun: setsun $(OBJDIR)/$(OBJS) cc $(CFLAGS) -o X $OBJDIR)/$(OBJS) setsun: sunobj/$(OBJS) OBJDIR = sunobj foo.o: foo.c bar.h cc $(CFLAGS) foo.c mv foo.o $(OBJDIR) ============================================================ Joel Rives -- The thief Left it behind-- The moon at the window. -Ryokan
jef@unisoft.uucp (Jef Poskanzer) (10/28/87)
In the referenced message, jjo@calmasd.UUCP (Jay Olson) wrote: }We have an environment which I am sure is becoming quite common these }days: a network with a variety of Suns, Vaxen and other assorted machines, }many of which run NFS and can see filesystems on other machines in the }network. Right now, the X11 source is NFS mounted so that both the Suns }and the Vaxen can access it. } }However, it is somewhat inconvenient to actually build and install X for }both types of machines using the same source. I found what seems to be a pretty good solution to this problem: I have a single source tree, and then for each target machine I have a shadow tree. In the shadow trees, all the source files are replaced by symbolic links to the original in the source tree. There are no symbolic links for object files, so they get stored in the shadow trees. To accomplish this, I wrote two simple scripts. The first creates a shadow tree from a source tree. The second allows you to use sccs even if you are in a shadow tree. If anyone wants these scripts, just mail me a request. --- Jef Jef Poskanzer unisoft!jef@ucbvax.Berkeley.Edu ...ucbvax!unisoft!jef "That must be wonderful! I don't understand it at all." ...and now, a word from our sponsor: "The opinions expressed are those of the author and do not necessarily represent those of UniSoft Corp, its staff, or its management."
mtr@eagle.ukc.ac.uk (M.T.Russell) (10/29/87)
Summary: Expires: Sender: Followup-To: In article <2496@calmasd.GE.COM> jjo@calmasd.UUCP (Jay Olson) writes: >We have an environment which I am sure is becoming quite common these >days: a network with a variety of Suns, Vaxen and other assorted machines, >many of which run NFS and can see filesystems on other machines in the >network. Right now, the X11 source is NFS mounted so that both the Suns >and the Vaxen can access it. > >However, it is somewhat inconvenient to actually build and install X for >both types of machines using the same source. If I have built one particular >version (say the Sun), and wish to make a small change to the other (say >the Vax), I have to make clean, possibly fiddle with some files, remake the >makefiles, remake the dependencies, and completely remake X. Needless to >say, this is quite time-consuming. We also have this configuration, and I have found one method which avoids doing complete rebuilds when you want to make a binary for a new machine (I haven't used it on the X sources yet, only my own programs). You have a single letter macro (I use M) which is defined differently for each machine ("sun_" on the sun, "vax_" on the vax etc). Then in the makefile call the .o files "foo.$Mo" instead of "foo.o". You supply a rule for making the .$Mo files from the .c files. You also prepend $M to the name of the binary or library to be made. Thus a typical makefile looks like this: # makefile for baz .c.$Mo: $(CC) $(CFLAGS) -c $*.c mv $*.o $*.$Mo OBJS = foo.$Mo bar.$Mo $Mbaz: $(OBJS) $(CC) $(CFLAGS) -o $Mbaz $(OBJS) foo.$Mo: foo.c foo.h bar.$Mo: bar.c foo.h bar.h If M is defined as "vax_", this builds foo.vax_o and bar.vax_o then links them to make vax_baz. If you change a source file (say foo.c) a remake will make foo.vax_o and vax_baz. If you then move to a Sun, the remake will make foo.sun_o and sun_baz. You either set $M in the environment, or if your version of make won't read the environment, have a shell script in your local bin: #! /bin/sh /bin/make "M=vax_" $* One advantage of this scheme is that you don't have to remember which machine you are on - just say "make" and the right target for the machine gets built. A disadvantage is that you can't have makes running simultaneously on different machines - the temporary .o files clash. It the -o flag for cc worked with -c this wouldn't be a problem. Also, the Sun cc whines verbosely about files with a unknown suffix being passed to ld (but makes the binary OK). Mark Russell mtr@ukc.ac.uk
dms@WHEATIES.AI.MIT.EDU (David M. Siegel) (10/29/87)
I'd like your shell scripts. Thanks!
bob@aargh.cis.ohio-state.edu (Bob Sutterfield) (10/30/87)
In article <2496@calmasd.GE.COM> jjo@calmasd.UUCP (Jay Olson) writes: > ... a variety of Suns, Vaxen and other assorted machines, many of >which run NFS and can see filesystems on other machines in the >network. Right now, the X11 source is NFS mounted so that both the >Suns and the Vaxen can access it ... We have similar problems. Our master source directory tree is on a Pyramid, but we would like to be able to build stuff on each of several different machines (Sun2, Sun3, soon Sun4, soon HP 330s and 350s, etc.). I find the following shell script "lndir" to be very useful. It makes a tree of links: The directories are real, but all files are symbolic links, usually across NFS to the actual sources. The current exception is that anything named Makefile is copied because that's where most of the machine customizations happen This script still requires some manual postprocessing. For example, you will need to make all your GNU Emacs *.elc files "real" on the new directory tree if you want to be able to use workstations while the central source machine is down. Similarly, emacs/src/config.h and friends are locally-customized. X11 may require manual local machine-specific futzing of Imakefiles, too. But the massive bulk of the work of building a tree of links is done for you. Since the script is fairly simple and very helpful, I've included it here. Hope this helps! ------------------------------------------------- #!/bin/csh -f foreach n ($*) if (-d $n) then mkdir $n:t cd $n:t foreach m ($n/*) /usr/local/bin/lndir $m end cd .. else # Here is where other special cases can be inserted if ($n:t == Makefile) then echo Copying $n cp $n . else ln -s $n endif endif end ------------------------------------------------- -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@ohio-state.{arpa,csnet} or ...!cbosgd!osu-cis!bob soon: bob@cis.ohio-state.edu