Date: Tue, 4 Apr 1995 16:54:41 -0600 From: Nate Williams <nate@trout.sri.MT.net> To: rkw@dataplex.net (Richard Wackerbarth) Cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Message-ID: <199504042254.QAA07754@trout.sri.MT.net> In-Reply-To: rkw@dataplex.net (Richard Wackerbarth) "Re: cvs commit: src/sys/i386/conf Makefile.i386" (Apr 4, 5:25pm)
next in thread | raw e-mail | index | archive | help
> >Where genassym is built is a moot point?
> >
> >> Since the two versions are linked against different libraries, it is
> >> important that thare is NO ABSOLUTE reference to any file. All references
> >> MUST be RELATIVE to the environment in which the code will be executed.
> >
> >One version is built on the cross. machine, and another version is built
> >on the host machine.
>
> Not necessarily. I should be able to build Genassym on th host machine,
> later to be run on the cross machine.
Huh? If you can build it on the host machine, then do it there. Doing
part of the kernel compile on the cross machine and part of it on the
target machine is just silly.
> There is no portion of the systen
> that I should not be able to pre-compile and then install. That way, a
> future "make" does not need to un-necessarily recompile those things that
> have not changed.
'genassym' is a temporary program used in the kernel compile process. It
exists solely for kernel compiles. It can be called a 'tool', but it's
a very poor definition since it's only used once.
> Genassym is logically no different that say gcc. It is a tool that I will
> need to compile a new kernel.
But genassym is not built separately. It is built as *part* of the
kernel compile process.
I'm goint to shutup now since the point of the arguement is lost. I
have *much* better things to do than argue about what tools should
be built by the cross compiler and what should be built native.
We are both arguing about something which is such a trivial bug in the
system which affects < .01% of the users, when there are bugs that affect
90-100% of the users.
You want to completely throw away the entire build process as it is now.
That's *NOT* going to happen anytime soon.
> So far, the ONLY reason expressed ("I don't like it" isn't a reason)
> against such a scheme is that I propose to keep the object in a parallel
> tree rather than using the "obj" links presently used.
1) Is really any better than what we have for the majority of the users. There
are much bigger fish to fry, but you are welcome to go off and do
this yourself.
2) Is it feasible?
3) Will you do all the work required to make it work right
No more on this topic from me. (The group sighs with relief)
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504042254.QAA07754>