[newsham@aloha.net (Timothy Newsham) writes:]
>...[multiple architecture source tree]...
I'm planning on using symbolic links. Where you currently see
"../mach/<file>" you would instead see "../@MACH/<file>". @MACH expands to
the value of the environment variable "MACH" for a given process. During
bootup we would put "isa386", "amiga68k", and so forth as a global value for
the MACH environment variable.
>the os/make directory is a shared directory. I modified the
>config program to take an optional arch parameter. This parameter
>specifies a subdirectory to get the 'files', 'objs', 'make.head'
>and 'make.tail' directories if specified. This allows the files
>and definitions to be different for each arch.
How about an "include @MACH/makefile" in the main one?
>libc. My libc makefile was hacked up a bit. The mach directory
>under libc doesnt have a makefile and so the libc makefile
>accesses the mach directory directly. I do not have the same
>list of files in this directory as the i386 port. I also
>make a libkern.a library and moved utility routines out of
>locore.s. My 'ar' program also doesnt support all the same
>flags and so I had added an ARFLAGS variable in my makefile
>(this last problem is minor and will go away when I compile
>native or use the same toolset). Anyway the end result
>is that my makefile for libc is different in a few places
>and cant easily be shared between archs. Is there a simple
>solution?
It seems like another makefile include might handle this as well?
>I personally think a tree where all the mach dependant device
>drivers, kernel code and librarires were under on directory
>would be better.
I lived with such a tree for HP/UX's command source. It wasn't that great.
I've generally been happier with mach/ (@MACH/) subdirectories and all
source for a given command (or kernel) in close proximity.
Regards,
Andy
Received on Mon Feb 13 09:42:28 1995
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:17 PDT