On Mon, Feb 25, 2008 at 7:31 AM, Marco Peereboom <[EMAIL PROTECTED]> wrote: > You want to read lndir(1).
This is extremely helpful advice, thank you! I used lndir to create an architecture specific copy of my source tree, and successfully built a release within it. So, this is one way to do what I requested, and is a successful workaround. After I built my release, I checked the arch specific src tree for files that were not symbolic links, using: find . -type f -print All resulting found files were in the ./sys/arch/`machine`/compile directory tree. This leads me to believe that only the compile directory needs to be written to by the make release process. I find it inconsistent and less than optimal that the build of userland pretty much requires the use of a seperate obj directory BSDOBJDIR, the src tree is defined in BSDSRCDIR, and the release and dest directories required by make release are defined as RELEASEDIR and DESTDIR, and all these directories can be defined in distinct separate areas, but that the compile directory used by make release cannot be similarly defined in an alternate location than its default location within BSDSRCDIR. So, I have a gentle request/proposal that the compile directory used by the make release process be specified in some new environment variable (BSDCOMPILEDIR ?), if defined, that location is used as the base for compiling GENERIC, GENERIC.MP, etc, and if undefined, the existing default behavior would be followed. I can imagine that the lndir solution works great (and maybe better) for a certain class of developers/builders/users (maybe people that are constantly building versions of CURRENT?), but I believe that the class of OpenBSD users that follow STABLE and need to support multiple architectures would benefit from this seemingly small and straightforward change to the make release process. The lndir solution works, but is not perfect (just read about some of the caveats in the lndir man page) when things start to diverge between the two subtrees. My proposal above would eliminate the issues created by having link trees back to the virgin source. Best regards, Don Jackson > On Sun, Feb 24, 2008 at 11:27:31PM -0800, Don Jackson wrote: > > The FAQ describes two ways to build the kernel ( > > http://www.openbsd.org/faq/faq5.html#BldKernel ), > > > > # cd /usr/src/sys/arch/i386/conf > > # config GENERIC > > # cd ../compile/GENERIC > > # make clean && make depend && make > > > > or > > Variation on above process: Read-only source tree > > Sometimes, you may wish to ensure your /usr/src/sys directory > > remains untouched. This can be done by using the following process: > > $ cd /somewhere > > $ cp /usr/src/sys/arch/i386/conf/GENERIC . > > $ config -s /usr/src/sys -b . GENERIC > > $ make clean && make depend && make > > > > I would like "make release" to use the "read only source tree" variant > > above, how can I accomplish this? > > > > Right now, I see "make release" do: > > > > cd /home/4.2/src/etc/../sys/arch/amd64/conf && config GENERIC > > > > Which is going to attempt to build the GENERIC kernel right there in > > my source tree. > > > > Also, I am having some other weird problem, due to the following logic > > in the Makefile.amd64 which contains: > > > > # source tree is located via $S relative to the compilation directory > > .ifndef S > > S!= cd ../../../..; pwd > > .endif > > AMD64= $S/arch/amd64 > > > > For some reason the above is setting my AMD64 to some weird path that > > is not correct on my system, namely: > > > > cd /home/4.2/src/etc/../sys/arch/amd64/conf && config GENERIC > > GENERIC:13: cannot open ../../../../arch/amd64/conf/files.amd64 > > for reading: No such file or directory > > > > *** Error code 1 > > > > Stop in /home/4.2/src/etc (line 11 of etc.amd64/Makefile.inc). > > > > What is the point of the above, and how can I get the path correct for > > this build? > > > > Thanks, > > > > Don
