9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Jacob Moody <moody@mail.posixcafe.org>
To: 9front@9front.org
Subject: Re: [9front] Beware of 'mk nuke': mkrunetype.c
Date: Wed, 29 Mar 2023 09:16:12 -0600	[thread overview]
Message-ID: <c2ce9085-47d7-20d2-dd01-88378eb2136a@posixcafe.org> (raw)
In-Reply-To: <C939064CC2DB48D282245384BF32A4EE@smtp.pobox.com>

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



  reply	other threads:[~2023-03-29 15:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29  7:24 Romano
2023-03-29  7:29 ` Jacob Moody
2023-03-29 14:41   ` unobe
2023-03-29 15:16     ` Jacob Moody [this message]
2023-03-29 18:53       ` Jacob Moody
2023-03-29 20:19         ` 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=c2ce9085-47d7-20d2-dd01-88378eb2136a@posixcafe.org \
    --to=moody@mail.posixcafe.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).