From: cinap_lenrek@felloff.net
To: 9front@9front.org
Subject: Re: [9front] Re: [9front-commits] cinap_lenrek: hg/plan9front: vmx: build vmx only for 386 or amd64
Date: Wed, 1 May 2019 16:21:11 +0200 [thread overview]
Message-ID: <45FA5E7888DB65CD7C1B931D3879C2A5@felloff.net> (raw)
In-Reply-To: 788063b9-d407-4792-b90a-1323b102f083@iPhone
because it is supported. but yeah, i agree that amd64 is the most
*practical* option... also as you need lots of memory in the machine.
the real question is how we should deal with non portable programs
in the build.
maybe there should be a /sys/src/cmd/$objtype/ where we put cpu specific
programs? that way i can skip building vmx completely for non 386 or
amd64 builds. or like "platform" source directory like /sys/src/cmd/pc/
where we put all the pc specific stuff.
possible answers:
there are no non-portable programs. it will always compile, and
when run yield a error message when run on the wrong cpu type.
(thats how we managed so far)
exclude all non-portable programs from /sys/src/cmd/mkfile
(setting $NOMK) so user has to compile it manually by entering
the directory and typing "mk" with an appropriate $objtype.
non-portable programs ignore the $objtype and always build for
ther *ONE* possible cpu type. (we pick amd64 as the only one)
non-portable programs selectively override $objtype when compiling
for unsupported cpu type. (thats what this commit did)
extend the mkfiles to support actual selectively building stuff
based on $objtype. this would cover all cases.
--
cinap
next reply other threads:[~2019-05-01 14:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-01 14:21 cinap_lenrek [this message]
2019-05-03 21:14 ` Ethan Gardener
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=45FA5E7888DB65CD7C1B931D3879C2A5@felloff.net \
--to=cinap_lenrek@felloff.net \
--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).