From owner-freebsd-current Tue Apr 4 15:25:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA24574 for current-outgoing; Tue, 4 Apr 1995 15:25:54 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA24562 for ; Tue, 4 Apr 1995 15:25:52 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id PAA19925 for ; Tue, 4 Apr 1995 15:22:57 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Tue, 4 Apr 1995 17:25:23 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Apr 1995 17:25:25 -0500 To: Nate Williams From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com Sender: current-owner@FreeBSD.org Precedence: bulk Nate Williams 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