Date: Sat, 28 Jan 1995 06:11:07 -0600 From: rkw@dataplex.net (Richard Wackerbarth) To: Bruce Evans <bde@zeta.org.au> Cc: hackers@FreeBSD.org Subject: Re: REMAKE WORLD Message-ID: <v02110102ab4fd889db37@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
>>1. The build procedure should run on any machine that meets certain minimal
>>specs. (Like maybe 1.1.5.1) Doing a build will in NO way affect the host
>>environment.
>
>Too hard for 1.1.5.1. Require 2.1.
Come now, 2.1 doesn't even exist. I can certainly set up a procedure that
runs on a 2.0 system, and off hand, I don't see anything about 1.1 that
precludes it.
After all, what do we need? The ability to execute gcc, make, etc. There is
nothing to say that these are the native versions.
Remember, one of the goals is that we don't affect the running system. As a
result, every reference MUST be to our own tree of {tools, sources,
includes, libraries, objects, binaries, and installation} files. As long as
we can compile the tools on a system, we can do it. I will make one
concession. I will require the OS to support certain Unix commands and
features. At this point, I don't know just what the minimal set is. I know
MSDOS won't hack it because of file name problems, but I am not sure just
how far back in Unix we need to go in order to run our tools.
>>2. If everything is up to date, a make will do nothing except scan the
>>tree. Nothing gets rebuilt unless it is out of date.
>
>I have parts of this for 2.0. For `make; make install; make; make
>install', the second make does nothing and the second install changes
>very few timestamps although it is reinstalls almost everything.
Gim'me! Gim'me! Assuming that you are willing to colaborate, my task may
not be quite as hard.
>This requires mainly not clobbering timestamps when installing unchanged
>files. Making the world is harder, and most of the dependencies on
>libc.a are bogus.
Libc.a should not change if "make" does it's job properly. After all, what
is magic about building a library? The output file depends on the objects
just like any other part of the chain. If the library is up to date, make
does nothing.
>Links are normally done to ${SHLIBDIR}/libc.so.2.0.
>These should be done to /usr/obj/lib/libc/libc.so.2.0, and the linkage
>is not supposed to depend on the library file, only on the library
>version.
So we add shared library "cookies" that get changed only with the version
number.
>What is "nothing"? I'd like it to be nothing more than reading Makefiles
>and stat()ing files to get timestamps. No building temporary files.
I'd like that, too.
>>5. Multiple targets can co-exist at the same time. The entire process has a
>>floating root. No path is hard coded.
>
>This makes it hard to check out a single module outside of the source
>tree and build it.
It may be hard, but I don't really think impossible. Basically, you float
EVERYTHING off of {SRCDIR}, {DESTDIR} type elements.
>>4. The make procedure is not allowed to "touch" it's input tree. The source
>>tree can be read-only. The object tree can be read-only if up-to-date.
>>6. Symbolic links are permitted. (This is a hard one because /../ does not
>>necessarily get you back where you were :-( )
>
>This is a bit inconsistent with (4). I think requiring obj links in the
>source tree would be best.
What is inconsistent?
Obj links are not consistent with (5).
----
Richard Wackerbarth
rkw@dataplex.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02110102ab4fd889db37>