Re: [9front] Re: system mkfile changes

[Amavect <amavect@gmail.com>]

On March 27, 2021 10:00:27 AM CDT, cinap_lenrek@felloff.net wrote:
>this is tricky, i think using ls here is better
I believe I was trying to avoid `ls *.[cy]`, which is marginally slower locally, and very slow over a network versus plain `ls`.
Umbraticus' suggestion works great.

The CPDEP stuff was me thowing my hands in the air. Sorry about that.

>the rest of the mkfiles should be able to always rely on that the
>currently
>installed binaries for compilers, linkers, assemblers, yacc, mk, cp,
>awk,
>sed, grep, rc shell are the correct ones.
>
>these races should never exist if we have clear separation of build
>and installation, and the install step makes sure its not relying on
>the very
>tools it is currently installing.
I wanted to avoid serializing the install rule, because that screws up mk's ability to read dependencies.
Perhaps the best solution is to put cp and yacc in their own directory. Maybe a /sys/src/base directory could hold the build environment sources.

Anyways, I gave up.
There's now a small chance of the user specifying install targets manually and getting an ioerror as yacc and cp get installed.
Here's the latest tarball.
https://git.sr.ht/~amavect/mkfilechanges/archive/master.tar.gz

>To build the toolchain, you also need to build their library
>dependencies,
>which is also not stated in the mkfiles.
This is a limitation of mk.
I would love to "import" the rules to build those dependencies from anywhere in the src tree, and finally solve the issue of recursive mk. I have some ideas brewing there.

Thanks,
Amavect