[Bug 215541] ports-mgmt/poudriere-devel: -r428604: -x (native-xtools) ignores MAKEOBJDIRPREFIX for XDEV_TOOLS; more

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215541

            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 at FreeBSD.org
          Reporter: markmi at dsl-only.net
             Flags: maintainer-feedback?(bdrewery at FreeBSD.org)
          Assignee: bdrewery at 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="..."

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.)

-- 
You are receiving this mail because:
You are the assignee for the bug.