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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 7652 invoked from network); 25 Mar 2021 19:40:37 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 25 Mar 2021 19:40:37 -0000 Received: from mail-qk1-f181.google.com ([209.85.222.181]) by 1ess; Wed Mar 24 14:44:23 -0400 2021 Received: by mail-qk1-f181.google.com with SMTP id x14so19094864qki.10 for <9front@9front.org>; Wed, 24 Mar 2021 11:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:from:message-id; bh=RqzUGl2K+66JdPmtv6ZstxsF3ktrr3TxyOim/10Akdo=; b=TI/UefIuJAVZSoNKA3ao9N0NKbvZ1u7JHBachrcUb++DwLApq0UUoGcQ/+qSCd31Wf +tu2kbuKli+S5zVe5dQD7zJqltJ8WdI1lBtbLlKcM1sOz9v+sRBZICIMVsCEjxcDE1t/ Uud8DMfaksrPErclq+I39N5XdCowZWomm5O0ZXvUhrw0WkD/wSLYaPWJ8dOw66fAVAwP XvFCudvkQLb7r3Ej6B5x37kTkukA5fnCUno+QtXAFdH9FFKBTQUqHmgZ3ByovIFxWHNU I8NuiQ1b4x4e/nVojZKteFQmGYF/Zn7tS3yfz9ymYgeF6N10LksN1eZe0iLvulE9Mimp 2lRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:from:message-id; bh=RqzUGl2K+66JdPmtv6ZstxsF3ktrr3TxyOim/10Akdo=; b=BkWjUbUiRxqIeNFgrdHTkqNpX9RO4mDOjQ93S9yc4SGNyBrrvZ9l189IeAIIfB2sQM mcVDSzELYR63ByETcqCQWn8ya6HCKTKVVH3zgr5QIV+LJbDJ3KCAMpmDA+TCDLIP+BiO diSUgyu6TfOIZCNBI2B7LxTHWe8hJbG/wKFUVdfWFDq/srwyRWkavWIKGbjKax1sYPNW L0jpfQNdAvemW9mCk+bi0kz3dpSL7tRsx+zpKsXeFqCZmCguarZKUod0WuhKieydEgzd hZe2o6bu58xKCnJRYBte4jNlNXmP2a0QvSgFTscKeRRKcO9P6M02fh+7j9qD3VlXeGFA r+aA== X-Gm-Message-State: AOAM533s7ALAHG87x9qA7uNTMKgLAU6+fGbEqeU7TDVGaG8a4VZ6WxlN dRnUqGhjg46luX+Ad6e6/GecaFAepTg= X-Google-Smtp-Source: ABdhPJxunbyTsakn9TCOHjNbQvL/KOiuFUKtvfAioQi4THGe+JKDggLiixmI990pZnlpGjZTcxJe0g== X-Received: by 2002:a37:6453:: with SMTP id y80mr4396716qkb.291.1616611452323; Wed, 24 Mar 2021 11:44:12 -0700 (PDT) Return-Path: Received: from ?IPv6:2601:246:4e03:dc20:c938:6479:987c:e6ad? ([2601:246:4e03:dc20:c938:6479:987c:e6ad]) by smtp.gmail.com with ESMTPSA id m21sm2259831qka.28.2021.03.24.11.44.11 for <9front@9front.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Mar 2021 11:44:11 -0700 (PDT) Date: Wed, 24 Mar 2021 13:44:09 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <25513311-9758-438C-B981-A50655DC183C@gmail.com> References: <25513311-9758-438C-B981-A50655DC183C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: 9front@9front.org From: Amavect Message-ID: <357BEDBC-499F-420D-BFB7-CF8C1B37B95D@gmail.com> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: WEB2.0 extension app cloud DOM backend Subject: [9front] Re: system mkfile changes Reply-To: 9front@9front.org Precedence: bulk All, There was some criticism on IRC relayed to me=2E My /sys/src/cmd/mkfile change would build cp and yacc instead of copying t= hem locally=2E A philosophical concern was brought up about the new mkfile assuming the b= uild environment was incorrect=2E That is not a problem the new mkfile intends to solve=2E It solves the following problems: 1=2E There's a race between installing cp or yacc and their next invocatio= n=2E 2=2E cp and yacc should be built first if there were any changes=2E 3=2E Installing cp is a circular dependency=2E Reason 1 makes no assumption whether writing to the disk file system is at= omic=2E Reason 2 is why it's better to build yacc than copy from /bin=2E Reason 3 is why it's better to build cp than copy from /bin=2E Thus, building from scratch is too convenient=2E Why not just install cp and yacc at /sys/src/mkfile to solve problems 2 an= d 3? Now cp and yacc need to be excluded from cmd/mkfile's TARG to solve proble= m 1=2E But now, cmd/mkfile's mk install no longer builds everything=2E So why have cp and yacc there in the first place? Alternatively, move cp and yacc to a different directory that represents p= rograms used for the build environment=2E This avoids the exceptions=2E I'm not against that=2E An argument brought up was that LDFLAGS is not always set the same across = architectures=2E This is absurd=2E No /$objtype/mkfile sets LDFLAGS=2E Additionally, both the old and the new /sys/src/cmd/mkfile set LDFLAGS to = be nothing! For special cases like spim, 0l is an rc script around vl that injects the= flag, so its interface is the same=2E Unless there are concrete plans to make each linker's flag interface diffe= rent, this argument is wrong=2E There's an improvement that was not mentioned=2E $Ocpu can be eliminated= =2E If $objtype to $cputype match, then cp and yacc need to be built from scra= tch to avoid problems=2E As a result, the CC and LD rules can be reverted to non-regexp form, solvi= ng any supposed LDFLAGS issues=2E I have updated the repo reflecting these changes=2E https://git=2Esr=2Eht/~amavect/mkfilechanges Thanks, Amavect