Date: Sat, 24 Dec 2016 23:35:55 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 215541] ports-mgmt/poudriere-devel: -r428604: -x (native-xtools) ignores MAKEOBJDIRPREFIX for XDEV_TOOLS; more Message-ID: <bug-215541-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215541 Bug ID: 215541 Summary: ports-mgmt/poudriere-devel: -r428604: -x (native-xtools) ignores MAKEOBJDIRPREFIX for XDEV_TOOLS; more Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: bdrewery@FreeBSD.org Reporter: markmi@dsl-only.net Flags: maintainer-feedback?(bdrewery@FreeBSD.org) Assignee: bdrewery@FreeBSD.org [Note this is based on analyzing what issue might happen in my first experiments with poudriere --or what I might need to avoid because of issues that might be involved.] If export MAKEOBJDIRPREFIX=3D"..." is used in a /usr/local/etc/*poudriere.conf but -x is in use for a pourdriere jail command that puts it to use then XDEV_TOOLS ignores the MAKEOBJDIRPREFIX=3D and looks in : /usr/obj/${TARGET}.${TARGET_ARCH}/nxb-bin no matter what. Or going the other way for the intent: MAKEOBJDIRPREFIX=3D would likely prevent the result from being in the above path as required by the below code. (Prevent MAKEOBJDIRPREFIX use?) build_and_install_world() { . . . if [ ${XDEV} -eq 1 ]; then msg "Starting make native-xtools with ${PARALLEL_JOBS} jobs" ${MAKE_CMD} -C /usr/src native-xtools ${MAKE_JOBS} \ ${MAKEWORLDARGS} || err 1 "Failed to 'make native-xtool= s'" XDEV_TOOLS=3D/usr/obj/${TARGET}.${TARGET_ARCH}/nxb-bin . . . As, I never use the default MAKEOBJDIRPREFIX but instead identify multiple variations built from the same source systematically and more explicitly, I'd have to violate my normal naming to use -x as stands . The -C /usr/src above is also the only example of that hardwired path. (There are lots of ${JAILMNT}/usr/src examples.) The -C would not seem to track a -P patch'd SRC_BASE area. What if a potential system clang update were to be tested for targeting some architecture (such as powerpc64 or powerpc) via -x? Context: # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 428604 Last Changed Rev: 428604 Currently -m src=3D use would require separately doing steps equivalent to the ${XDEV} -eq 1 logic to set such up but the logic is not factored out where it can be used to complete a poudriere context for XDEV_TOOLS use. Currently use of something like -m svn+https and -P patch-file would be required for simple, direct poudriere use to experiment with system-clang compiler patches for targeting a, say, powerpc64 or powerpc or other such. At least once -P is respected by -x . Note: I tend to have the same system source patches in place for each architecture that I try, making sure that architecture specific ones do not mess up the other architectures from building. That includes when I'm testing a system clang patch for someone. (Normally a powerpc family issue is being addressed.) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-215541-13>