Re: [9front] Re: [9front-commits] cinap_lenrek: hg/plan9front: vmx: build vmx only for 386 or amd64

Re: [9front] Re: [9front-commits] cinap_lenrek: hg/plan9front: vmx: build vmx only for 386 or amd64

[cinap_lenrek]

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

Re: [9front] Re: [9front-commits] cinap_lenrek: hg/plan9front: vmx: build vmx only for 386 or amd64

[Ethan Gardener]

On Wed, May 1, 2019, at 3:21 PM, cinap_lenrek@felloff.net wrote:
> 
> non-portable programs selectively override $objtype when compiling
> for unsupported cpu type. (thats what this commit did)

I'd (slightly) prefer it successfully did nothing than build unnecessarily.