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.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 12454 invoked from network); 29 Mar 2023 15:18:07 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 29 Mar 2023 15:18:07 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed Mar 29 11:16:58 -0400 2023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1680103361; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rTcqYLyQWu8tK9mhFSXqNPmx4keUCe1G7ckOZBarlB8=; b=Ml7XXBaQhce4phqcVWhSiYyU1Rn6SesClmYh3Jvdgeye3dgpzJFs66hRuu2CISqBeRMfwe MKYL1R2/WXghPIoy0F1DwlLPX9R0fF19VXRwZPbhBEZ+NgGO8cw9IwtEboqU4bzGf39qCI JudAVh7BtihZTsTAQ0+LXFjc7Ge0nP0= Received: from [192.168.168.200] (161-097-205-025.v4.mynextlight.net [161.97.205.25]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 9b441c71 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Wed, 29 Mar 2023 10:22:40 -0500 (CDT) Message-ID: Date: Wed, 29 Mar 2023 09:16:12 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Content-Language: en-US To: 9front@9front.org References: From: Jacob Moody In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: dependency singleton Subject: Re: [9front] Beware of 'mk nuke': mkrunetype.c Reply-To: 9front@9front.org Precedence: bulk On 3/29/23 08:41, unobe@cpan.org wrote: > Quoth 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? > > Yes. I should have mentioned what commit I was on, sorry. > > cpu% git/log -n 1 > Hash: 503862f9000943b5cd72c1511828bae0c2050adc > Author: Sigrid Solveig Haflínudóttir > 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