9front - general discussion about 9front
 help / color / mirror / Atom feed
From: unobe@cpan.org
To: 9front@9front.org
Subject: [9front] [PATCH] mk for only supported archs
Date: Tue, 17 Aug 2021 07:00:47 -0700	[thread overview]
Message-ID: <8FA58107FDEFD99779044B4B0D7E6B8B@smtp.pobox.com> (raw)

http://fqa.9front.org/fqa1.html#1.2 states the supported archs.
However, clean and nuke also remove build files for 0 (spim) and q
(power).  'mk all' using those archs fails; 'mk kernels' also tries to
build all the kernels, even those which are not supported.  For
example, I tried to build the power arch (qc, qa, ql) and without
surprise it failed (when building dtracy): ...
mk dtracy
qc -FTVw dtracy.c
yacc -v -d -D1 parse.y
qc -FTVw cgen.c
qc -FTVw act.c
qc -FTVw type.c
 == regfree ==
REGISTER R0 <11> STRUCT DTAct cgen.c:302
 == regfree ==

REGISTER R0 <11> STRUCT DTAct act.c:266

 == regfree ==
qc -FTVw agg.c
cgen.c:299 unknown type in regalloc: STRUCT DTAct
cgen.c:299 bad opcode in gmove INT -> STRUCT DTAct
cgen.c:302 unknown type in regalloc: STRUCT DTAct
cgen.c:302 bad opcode in gmove INT -> STRUCT DTAct
cgen.c:302 error in regfree: 0 [0]
REGISTERmk: qc -FTVw cgen.c  : exit status=rc 387386: qc 387392: error R0
 <11> STRUCT DTAct act.c:269

act.c:250 unknown type in regalloc: STRUCT DTAct
act.c:250 bad opcode in gmove INT -> STRUCT DTAct
act.c:266 unknown type in regalloc: STRUCT DTAct
act.c:266 bad opcode in gmove INT -> STRUCT DTAct
act.c:266 error in regfree: 0 [0]
act.c:269 unknown type in regalloc: STRUCT DTAct
act.c:269 bad opcode in gmove INT -> STRUCT DTAct
act.c:269 error in regfree: 0 [0]
act.c:274 unknown type in regalloc: STRUCT DTAct
act.c:274 bad opcode in gmove INT -> STRUCT DTAct
act.c:274 error in regfree: 0 [0]
too many errors
mk: for(i in cc ...  : exit status=rc 382748: rc 387379: mk 387381: error
mk: date for (i ...  : exit status=rc 373781: rc 382226: mk 382227: error
cpu%

The patch below skips over non-supported architectures.  Is that
something we want?  This way, 'mk kernels' should work without a
problem (tested on amd64).  Then if someone works on getting those
architectures supported again in the future, they can be added back
in.

--- //.git/fs/object/cfebf83947550f3ae730cef4a9b1ab6bf6b8d4f7/tree//sys/src/9/mkfile
+++ /sys/src/9/mkfile
@@ -3,11 +3,13 @@
 	bcm64\
 	cycv\
 	kw\
-	mtx\
+#	power arch:\
+#	mtx\
 	omap\
 	pc\
 	pc64\
-	ppc\
+#	power arch:\
+#	ppc\
 	sgi\
 	teg2\
 	xen\
--- //.git/fs/object/cfebf83947550f3ae730cef4a9b1ab6bf6b8d4f7/tree//sys/src/boot/zynq/mkfile
+++ /sys/src/boot/zynq/mkfile
@@ -7,6 +7,9 @@
 
 all:V: $TARG
 
+install:V:
+	echo install not supported >[1=2]
+
 clean:V:
 	rm -rf $TARG *.$O
 	@{objtype=$cputype mk -f mkfile.port clean}
--- //.git/fs/object/cfebf83947550f3ae730cef4a9b1ab6bf6b8d4f7/tree//sys/src/mkfile
+++ /sys/src/mkfile
@@ -1,5 +1,12 @@
 </$objtype/mkfile
 
+SUPPORTED_OBJS=\
+	386\
+	amd64\
+	arm\
+	arm64\
+	mips\
+
 LIBS=\
 	lib9p\
 	libString\
@@ -52,10 +59,14 @@
 
 all install clean nuke:VQ:
 	date
-	for (i in $LIBS $SUBSYS $CMDS) @{
-		cd $i
-		mk $target
+	if (~ $objtype $SUPPORTED_OBJS) {
+		for (i in $LIBS $SUBSYS $CMDS) @{
+			cd $i
+			mk $target
+		}
 	}
+	if not
+		echo $objtype arch not supported by 9front >[1=2]
 	date
 
 installall:V:
@@ -62,11 +73,15 @@
 	echo "installall not supported"
 
 release:V:
-	mk nuke
-	rm -f /$objtype/lib/ape/*.a
-	rm -f /$objtype/lib/*.a
-	mk install
-	mk clean
+	if (~ $objtype $SUPPORTED_OBJS) {
+		mk nuke
+		rm -f /$objtype/lib/ape/*.a
+		rm -f /$objtype/lib/*.a
+		mk install
+		mk clean
+	}
+	if not
+		echo $objtype architecture not supported >[1=2]
 
 kernels:V:
 	for (i in 9 boot) @{


             reply	other threads:[~2021-08-17 14:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-17 14:00 unobe [this message]
2021-08-17 15:53 ` Amavect
2021-08-17 20:15   ` unobe
2021-08-21  8:27     ` unobe
2021-08-22 14:15       ` cinap_lenrek
2021-08-22 14:33       ` cinap_lenrek
2021-08-22 15:13         ` Amavect
2021-08-18  3:00 ` ori
2021-08-18 22:47   ` unobe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8FA58107FDEFD99779044B4B0D7E6B8B@smtp.pobox.com \
    --to=unobe@cpan.org \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).