On 2017/01/23 11:55, Vadim Zhukov wrote: > 2017-01-23 4:04 GMT+03:00 Peter Hessler <[email protected]>: > > Here are some bits to add arch defines to the ports infrastruture files > > for aarch64. > > > > amd64 is the kernel arch (similar to macppc) > > aarch64 is the application arch (similiar to powerpc) > > I see no mention of arm64 in the diff you posted.
arm64 is not needed for the ARCHS defines, it would only appear on lines that have things like "loongson/macppc" instead of "mips64el/powerpc". > > Untested, but it is relatively straightforward. db/config.* already has > > information about armv8/arm64/aarch64. > > > > OK? > > > > Index: infrastructure/mk/arch-defines.mk > > =================================================================== > > RCS file: /cvs/openbsd/ports/infrastructure/mk/arch-defines.mk,v > > retrieving revision 1.30 > > diff -u -p -u -p -r1.30 arch-defines.mk > > --- infrastructure/mk/arch-defines.mk 1 Jan 2017 10:50:18 -0000 1.30 > > +++ infrastructure/mk/arch-defines.mk 23 Jan 2017 00:53:07 -0000 > > @@ -17,14 +17,15 @@ ALL_ARCHS = alpha amd64 arm aviion hppa > > # not all powerpc have apm(4), hence the use of macppc > > APM_ARCHS = amd64 i386 loongson macppc sparc64 > > BE_ARCHS = hppa m88k mips64 powerpc sparc64 > > -LE_ARCHS = alpha amd64 arm i386 mips64el sh > > -LP64_ARCHS = alpha amd64 sparc64 mips64 mips64el > > +LE_ARCHS = aarch64 alpha amd64 arm i386 mips64el sh > > +LP64_ARCHS = aarch64 alpha amd64 sparc64 mips64 mips64el > > +CLANG_ARCHS = aarch64 > > It's better describe in bsd.port.mk(5) what's the CLANG_ARCHS and > LLVM_ARCHS lists are, otherwise it gets quiet confusing. Agreed. I'm OK with the existing diff but please add this. > Also, you likely want to tweak clang.port.mk (to skip dependency and > correct cc/c++ links) and devel/llvm port (to skip it on CLANG_ARCHS), > unless you really want to keep devel/llvm port building on aarch64 and > make ports keep using this one instead of system compiler. I remember > sending a patch proposal to patrick@ some time ago... I disagree about skipping devel/llvm - it comes with many more things than we'd expect to be installed in base (and some things that _cannot_ be done in base, like the Python bindings). I agree that the clang module should use the compiler from base on those arches where it is already the base compiler. (Similar to what we did with the gcc3 module when we had gcc2+3 arches; use base compiler on gcc3 arches, use ports compiler on gcc2 arches). Should we rename files in the llvm port (e.g. eclang/eclang++/eclang-cpp)?
