Subject: Re: HOST_PROG ?
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Bill Studenmund <skippy@macro.stanford.edu>
List: tech-toolchain
Date: 12/15/1997 14:56:32
On Sun, 14 Dec 1997, Jason Thorpe wrote:

> On Sat, 13 Dec 1997 15:23:24 -0800 (PST) 
>  Bill Studenmund <skippy@macro.stanford.edu> wrote:
> 
>  > The main one right now is that the tn3270 code seems to want to run a lot
>  > of tools on the compiling computer. But it wants to use the standard CC,
>  > which is the cross cc. Bad things happen. :-(

Actually, I just stopped compiling tn3270. :-)

>  > So for now, I'm going to hack up the Makefiles (my local ones :-) to use
>  > HOST_CC & friends. But would it make sense to add a HOST_PROG and HOST_SRC
>  > targets to bsd.prog.mk? I think doing such a thing successfuly is a bit
>  > beyond me at the moment. ;-( Though it seems a cleaner solution.
> 
> I thought about doing something like athat at one point.  The real problem
> is that you need different .c.o rules, etc.  So, the existing bsd.*.mk
> file structure won't do HOST_PROG properly.

Hmm. Definitly new .c.o rules. But how much else would we need? I don't
think we need all of the bsd.*.mk hierarchy to work for HOST_PROG; the
idea is it's just for little programs needed to compile a program which is
part of the os.

Or, if we're trying to compile a really complicated "host" program, we
really shouldn't be doing it within the build system. We should just build
the program out-right and then use it. So I think it's ok to not expect a
HOST_PROG system to be as full-featured as the normal bsd.*.mk files. You
should NOT need a library for a "host" program, nor do I think machine
language would be reasonable.

I think that all the changes could be localized to bsd.prog.mk, in
something like the .if defined(PROG) section.

Or am I way off?

Take care,

Bill