Date: Tue, 4 Apr 1995 17:25:25 -0500 From: rkw@dataplex.net (Richard Wackerbarth) To: Nate Williams <nate@trout.sri.MT.net> Cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Message-ID: <v02120b05aba76e56bb05@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
Nate Williams <nate@trout.sri.MT.net> writes:
>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. 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 logically no different that say gcc. It is a tool that I will
need to compile a new kernel.
> Genassym won't run on the cross machine if it's compiled and linked
> with include files and libraries that exist for the target machine,
> and vice-versa.
Precisely why I insist that there are two contexts in which the code be
able to be compiled. In fact, this applies to ALL of the "tools", and that
includes much of the system.
Therefore, I conclude that ALL sources need to be "evaluated" in the
context of an environment, as described by an environment variable.
That variable would describe not only which sources, but also which
includes to use. It would also describe the appropriate libraries to be
linked and the "tools" to use in the creation.
What I would propose is that we establish a variable TREE (I am open to
other names) which designates a directory that contains everything needed.
It would have a directory of tools (bin), headers (inc[lude]), sources
(src), objects (obj), libraries (lib), and a destination directory (root).
Any of these could be populated with symbolic links to another tree. In
particular, I would allow this to be done at the directory level rather
than just at the file level. This is not to say that these links are
required, but that they are allowed and the system works when they are
used.
The one other thing that might be desirable would be a (link to) a
top-level Makefile.
In the default case, the "simple" user could simply use "/usr" as his tree.
If ${TREE} is not defined, the default rule would provide it.
Therefore, the simple user would not be affected. It is only the Makefiles
that are impacted.
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. Actually, the
current scheme already builds such a tree in /usr/obj. There is a "rule" to
make appropriate links to that tree so that "make" (and some hackers) can
find the objects. I propose to simply change the structure so that make
does not DEPEND on those links, but rather tracks its object tree from its
root. The "make obj rule" can then remain optionally available for those
who wish to maintain the status quo and have only one environment.
----
Richard Wackerbarth
rkw@dataplex.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02120b05aba76e56bb05>