From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 17464 invoked from network); 29 Oct 2022 20:41:13 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 29 Oct 2022 20:41:13 -0000
Received: from maat.thinktankworkspaces.com ([45.79.94.76]) by 9front; Sat Oct 29 16:40:05 -0400 2022
Message-ID: <B62BA9C5B78BA90191A27CBA1C0231CC@thinktankworkspaces.com>
To: 9front@9front.org
Date: Sat, 29 Oct 2022 13:40:03 -0700
From: william@thinktankworkspaces.com
In-Reply-To: <96d5d1bc-b961-94dc-61ce-c0268cabb331@posixcafe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: optimized DOM solution 
Subject: Re: [9front] 9front-8963.f84cf1e60427675514fb056cc1723e45da01e043.amd64.iso vs thinkpad x61t
Reply-To: 9front@9front.org
Precedence: bulk


I like all the ideas as long as its documented in fqa. My lazy self just simply forgets. 

I saved a copy of the shell script but twice I was on the wrong namespace while writting
to /n/9fat



Quoth Jacob Moody <moody@mail.posixcafe.org>:
> While looking over our mkfiles again I do see that we have a 'kernels' target
> in /sys/src that builds all of the kernels, but nothing for just the 'current'
> kernel. So I thought to add that, and add it to the list of subdirs
> we build on a 'install'. This defines the 'current' kernels/boot
> programs to those that are for the current objtype.
> 
> Now this doesn't do anything for putting the kernel somewhere other then /$objtype.
> Most kernel install targets have this notion of $EXTRACOPIES :
> 
> install:V:	$p$CONF
> 	cp $p$CONF /$objtype/
> 	for(i in $EXTRACOPIES)
> 		import $i / /n/$i && cp $p$CONF $p$CONF.gz /n/$i/$objtype/
> 
> This seems a bit oddly specific, perhaps EXTRACOPIES (or a rename) could be
> where someone puts in wherever they need the binary installed to
> You'd get something like:
> 
> cd /sys/src
> KDIRS=/n/9fat mk install
> 
> Just some thoughts, maybe this still sucks.
> 
> diff c67a1784cc34ffec633b61ad3267e13d162be219 uncommitted
> --- a//sys/src/9/mkfile
> +++ b//sys/src/9/mkfile
> @@ -19,7 +19,13 @@
>  		mk
>  	}
> 
> -installall install:V:
> +install:V:
> +	for(i in `{grep -l '^objtype='^$objtype */mkfile})@{
> +		cd `{basename -d $i}
> +		mk install
> +	}
> +
> +installall:V:
>  	for(i in $ARCH) @{
>  		cd $i
>  		mk install
> --- a//sys/src/boot/mkfile
> +++ b//sys/src/boot/mkfile
> @@ -10,7 +10,15 @@
>  		mk
>  	}
> 
> -installall install:V:
> +install:V:
> +	if(~ $objtype 'amd64')
> +		objtype=386
> +	for(i in `{grep -l '^objtype='^$objtype */mkfile})@{
> +		cd `{basename -d $i}
> +		mk install
> +	}
> +
> +installall:V:
>  	for(i in $ARCH) @{
>  		cd $i
>  		mk install
> --- a//sys/src/mkfile
> +++ b//sys/src/mkfile
> @@ -47,12 +47,15 @@
>  SUBSYS=ape\
>  	/acme\
> 
> +KERNS=9\
> +	boot\
> +
>  none:VQ:
>  	echo mk all, install, clean, nuke, release, kernels, or libs
> 
>  all install clean nuke:VQ:
>  	date
> -	for (i in $LIBS $SUBSYS $CMDS) @{
> +	for (i in $LIBS $SUBSYS $CMDS $KERNS) @{
>  		cd $i
>  		mk $target
>  	}
> @@ -69,10 +72,10 @@
>  	mk clean
> 
>  kernels:V:
> -	for (i in 9 boot) @{
> +	for (i in $KERNS) @{
>  		cd $i
>  		mk clean
> -		mk install
> +		mk installall
>  		mk clean
>  	}
>  ---
> 
> 
>