[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="..." 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= and looks in : /usr/obj/${TARGET}.${TARGET_ARCH}/nxb-bin no matter what. Or going the other way for the intent: MAKEOBJDIRPREFIX= 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-xtools'" XDEV_TOOLS=/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= 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.)
Is this a duplicate of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216083 ?
(In reply to Bryan Drewery from comment #1) There is overlap but this report also had additional material not referenced in 216083: QUOTE: 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? :END QUOTE That "-C /usr/src" use was in: 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-xtools'" XDEV_TOOLS=/usr/obj/${TARGET}.${TARGET_ARCH}/nxb-bin . . .
Oh, that is intended because native-xtools was broken. It was not building a sysroot so could only build against a source tree close enough to the host, hence /usr/src. I fixed that in head https://svnweb.freebsd.org/changeset/base/325001 Poudriere in git supports it as well, https://github.com/freebsd/poudriere/commit/ab3ac3346a1bbf0bb04a15515621272d1557cedb but have not yet updated the poudriere-devel port. I will include the fix in the next -devel update. Thanks for logging a bug!
A commit references this bug: Author: bdrewery Date: Fri Oct 27 23:11:19 UTC 2017 New revision: 453027 URL: https://svnweb.freebsd.org/changeset/ports/453027 Log: Update to 3.0-2583-g7913a064 - jail -x: Tell where native-xtools is being built - XDEV: Support the fixed native-xtools build target in FreeBSD head that builds from the Jail rather than the host system's /usr/src. [1] - Add XDEV_SRC_JAIL, if set will use the jail's source for xdev. This should only be used in special cases and will effectively default to on for head and soon for stable/11. - Record flavor for port build results. - jail -c: Fix EMULATOR being unset if ran via poudriered - Assert EMULATOR is not empty on use - .poudriere.ports.queued: Store flavor for dependencies - jail -x: Respect MAKEOBJDIRPREFIX [2] - jail -c: Disallow using a colon (:) in jail name. PR: 216083 [1] PR: 215541 [2] Changes: head/ports-mgmt/poudriere-devel/Makefile head/ports-mgmt/poudriere-devel/distinfo
A commit references this bug: Author: bdrewery Date: Sun Oct 29 01:20:11 UTC 2017 New revision: 453087 URL: https://svnweb.freebsd.org/changeset/ports/453087 Log: - Update to 3.1.22 Changes: https://github.com/freebsd/poudriere/wiki/release_notes_3122 PR: 216083 PR: 215541 Changes: head/ports-mgmt/poudriere/Makefile head/ports-mgmt/poudriere/distinfo
A commit references this bug: Author: bdrewery Date: Tue Nov 28 20:24:27 UTC 2017 New revision: 455072 URL: https://svnweb.freebsd.org/changeset/ports/455072 Log: MFH: r453087 r453882 - Update to 3.1.22 Changes: https://github.com/freebsd/poudriere/wiki/release_notes_3122 PR: 216083 PR: 215541 Avoid running git and finding PORTSDIR/.git. Reported by: xmj Approved by: portmgr (implicit) Changes: _U branches/2017Q4/ branches/2017Q4/ports-mgmt/poudriere/Makefile branches/2017Q4/ports-mgmt/poudriere/distinfo branches/2017Q4/ports-mgmt/poudriere-devel/Makefile