[9front] Beware of 'mk nuke': mkrunetype.c

[9front] Beware of 'mk nuke': mkrunetype.c

[Romano]

I haven't updated my system in a few months, and noticed the Unicode
changes so wanted to work with them.  I generally do a 'cd /sys/src &&
mk nuke && mk all', but that led to many errors.  I tried the
following:
* re-compile the compilers first (cc & 6c), which was successful; 6a &
  6l were not
* compile and install ape (successful)
* compile libc first (not successful), which led me to:
* compile the individual .c files in libc/port, which led me to
  mkrunetype.c still not compiling.

Yet I was still getting errors like the following:

cpu% cd /sys/src/libc/port
cpu% mk
@{
	eval `{grep '^[A-Z]' /$cputype/mkfile}
	6c -FTVw -o mkrunetype.6 mkrunetype.c
	6l $LDFLAGS -o 6.mkrunetype mkrunetype.6
	6.mkrunetype
}
param: undefined: _assert in param
getunicodeline: undefined: getfields in getunicodeline
estrtoul: undefined: strtoul in estrtoul
markbreak: undefined: strstr in markbreak
main: undefined: strcmp in main
main: undefined: exits in main
smprint: undefined: setmalloctag in smprint
fmtStrFlush: undefined: realloc in fmtStrFlush
fmtStrFlush: undefined: free in fmtStrFlush
fmtstrinit: undefined: malloc in fmtstrinit
dofmt: undefined: chartorune in dofmt
_fmtcpy: undefined: fullrune in _fmtcpy
_fmtcpy: undefined: runelen in _fmtcpy
_fmtcpy: undefined: runetochar in _fmtcpy
fmtstrcpy: undefined: utflen in fmtstrcpy
xdtoa: undefined: isNaN in xdtoa
xdtoa: undefined: isInf in xdtoa
xdtoa: undefined: tolower in xdtoa
xdtoa: undefined: frexp in xdtoa
xdtoa: undefined: pow10 in xdtoa
xdtoa: undefined: strtod in xdtoa
too many errors
mk: @{  eval ...  : exit status=rc 2050: rc 2052: 6l 2056: error

So I just kept updating the linking with the appropriate objects until it compiled. This is what I ended up with:
@{
	eval `{grep '^[A-Z]' /$cputype/mkfile}
	6c -FTVw -o mkrunetype.6 mkrunetype.c
	6l $LDFLAGS -o 6.mkrunetype mkrunetype.6 getfields.6 strtoul.6 strstr.6 strcmp.6 exits.6 _assert.6 rune.6 utfrune.6 malloc.6 lock.6 atol.6 pool.6 strtol.6 nan.6 strtod.6 toupper.6 frexp.6 pow10.6 utfecpy.6 atexit.6 fabs.6 utflen.6 ctype.6
	6.mkrunetype
}

I think it might be useful to have a proper patch for the mkfile under
libc/port.  Thoughts?

Re: [9front] Beware of 'mk nuke': mkrunetype.c

[Jacob Moody]

There was a brief window in which this was the case.

The commit 8b3154fb22991c0e96ca0c4e3658434791fc7e69 should have included the generated
files and remedied this issue.

Did you update past this and still have this issue?

On 3/29/23 01:24, Romano wrote:
> I haven't updated my system in a few months, and noticed the Unicode
> changes so wanted to work with them.  I generally do a 'cd /sys/src &&
> mk nuke && mk all', but that led to many errors.  I tried the
> following:
> * re-compile the compilers first (cc & 6c), which was successful; 6a &
>   6l were not
> * compile and install ape (successful)
> * compile libc first (not successful), which led me to:
> * compile the individual .c files in libc/port, which led me to
>   mkrunetype.c still not compiling.
> 
> Yet I was still getting errors like the following:
> 
> cpu% cd /sys/src/libc/port
> cpu% mk
> @{
> 	eval `{grep '^[A-Z]' /$cputype/mkfile}
> 	6c -FTVw -o mkrunetype.6 mkrunetype.c
> 	6l $LDFLAGS -o 6.mkrunetype mkrunetype.6
> 	6.mkrunetype
> }
> param: undefined: _assert in param
> getunicodeline: undefined: getfields in getunicodeline
> estrtoul: undefined: strtoul in estrtoul
> markbreak: undefined: strstr in markbreak
> main: undefined: strcmp in main
> main: undefined: exits in main
> smprint: undefined: setmalloctag in smprint
> fmtStrFlush: undefined: realloc in fmtStrFlush
> fmtStrFlush: undefined: free in fmtStrFlush
> fmtstrinit: undefined: malloc in fmtstrinit
> dofmt: undefined: chartorune in dofmt
> _fmtcpy: undefined: fullrune in _fmtcpy
> _fmtcpy: undefined: runelen in _fmtcpy
> _fmtcpy: undefined: runetochar in _fmtcpy
> fmtstrcpy: undefined: utflen in fmtstrcpy
> xdtoa: undefined: isNaN in xdtoa
> xdtoa: undefined: isInf in xdtoa
> xdtoa: undefined: tolower in xdtoa
> xdtoa: undefined: frexp in xdtoa
> xdtoa: undefined: pow10 in xdtoa
> xdtoa: undefined: strtod in xdtoa
> too many errors
> mk: @{  eval ...  : exit status=rc 2050: rc 2052: 6l 2056: error
> 
> So I just kept updating the linking with the appropriate objects until it compiled. This is what I ended up with:
> @{
> 	eval `{grep '^[A-Z]' /$cputype/mkfile}
> 	6c -FTVw -o mkrunetype.6 mkrunetype.c
> 	6l $LDFLAGS -o 6.mkrunetype mkrunetype.6 getfields.6 strtoul.6 strstr.6 strcmp.6 exits.6 _assert.6 rune.6 utfrune.6 malloc.6 lock.6 atol.6 pool.6 strtol.6 nan.6 strtod.6 toupper.6 frexp.6 pow10.6 utfecpy.6 atexit.6 fabs.6 utflen.6 ctype.6
> 	6.mkrunetype
> }
> 
> I think it might be useful to have a proper patch for the mkfile under
> libc/port.  Thoughts?
> 

Re: [9front] Beware of 'mk nuke': mkrunetype.c

[unobe]

Quoth Jacob Moody <moody@mail.posixcafe.org>:
> There was a brief window in which this was the case.
> 
> The commit 8b3154fb22991c0e96ca0c4e3658434791fc7e69 should have included the generated
> files and remedied this issue.
> 
> Did you update past this and still have this issue?

Yes.  I should have mentioned what commit I was on, sorry.

cpu% git/log -n 1
Hash:	503862f9000943b5cd72c1511828bae0c2050adc
Author:	Sigrid Solveig Haflínudóttir <sigrid@ftrv.se>
Date:	Tue Mar 28 09:13:19 -0700 2023

	truetypefs: fall back instead of crashing when could not get a glyph

cpu% git/log | grep 8b3154fb22991c0e96ca0c4e3658434791fc7e69
Hash:	8b3154fb22991c0e96ca0c4e3658434791fc7e69

Re: [9front] Beware of 'mk nuke': mkrunetype.c

[Jacob Moody]

On 3/29/23 08:41, unobe@cpan.org wrote:
> Quoth Jacob Moody <moody@mail.posixcafe.org>:
>> There was a brief window in which this was the case.
>>
>> The commit 8b3154fb22991c0e96ca0c4e3658434791fc7e69 should have included the generated
>> files and remedied this issue.
>>
>> Did you update past this and still have this issue?
> 
> Yes.  I should have mentioned what commit I was on, sorry.
> 
> cpu% git/log -n 1
> Hash:	503862f9000943b5cd72c1511828bae0c2050adc
> Author:	Sigrid Solveig Haflínudóttir <sigrid@ftrv.se>
> Date:	Tue Mar 28 09:13:19 -0700 2023
> 
> 	truetypefs: fall back instead of crashing when could not get a glyph
> 
> cpu% git/log | grep 8b3154fb22991c0e96ca0c4e3658434791fc7e69
> Hash:	8b3154fb22991c0e96ca0c4e3658434791fc7e69
> 

Ah okay, I am sorry I thought I had fixed this...
The issue is that even though the files are there mk
wants to update them. I am not exactly sure what the best way to properly
fix this is. I had thought to do what you had done and just select and tag
the specific pieces of libc needed for the generation but I didn't like that
approach too much. I'd sooner just vendor the bits needed in to mkrunetype.c,
perhaps that is the correct approach here?

One other thing people can do to get unstuck from this position is to
just remove the dependencies from the data rules, so mk doesn't want
to update them. Perhaps this is how it should be? Not sure, I am open
to suggestions on the right way to do this with mk.

apologies for this situation,
moody

diff 122cc66c1b10dea2b681ab4c924e598f669370ef uncommitted
--- a//sys/src/libc/port/mkfile
+++ b//sys/src/libc/port/mkfile
@@ -146,7 +146,7 @@
 /lib/ucd/%:
 	cd /lib/ucd && mk $stem

-runenormdata runetotypedata runeistypedata runebreakdata:	mkrunetype.c $UCD
+runenormdata runetotypedata runeistypedata runebreakdata:
 	@{
 		eval `{grep '^[A-Z]' /$cputype/mkfile}
 		$CC $CFLAGS -o mkrunetype.$O mkrunetype.c

Re: [9front] Beware of 'mk nuke': mkrunetype.c

[Jacob Moody]

I have modified the rules so that no automatic generation of these
files will be done, moving them to an explicit virtual rule. This
should prevent this happening in the future to anyone else.

For records this commit is:
997ea3e5ccd9cba5d1f8fad48a0320574696f5bc

Thank you again for your bug report,
moody

Re: [9front] Beware of 'mk nuke': mkrunetype.c

[unobe]

Quoth Jacob Moody <moody@mail.posixcafe.org>:
> I have modified the rules so that no automatic generation of these
> files will be done, moving them to an explicit virtual rule. This
> should prevent this happening in the future to anyone else.
> 
> For records this commit is:
> 997ea3e5ccd9cba5d1f8fad48a0320574696f5bc
> 
> Thank you again for your bug report,
> moody
> 

Confirmed, nuke'ing now doesn't exhibit the same behavior, and the
system builds.  Thanks, moody!