[Bug 276478] Mk/*: Build with a clean environment

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

            Bug ID: 276478
           Summary: Mk/*: Build with a clean environment
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Ports Framework
          Assignee: portmgr@FreeBSD.org
          Reporter: tijl@FreeBSD.org
                CC: acm@FreeBSD.org, amdmi3@FreeBSD.org,
                    gnome@FreeBSD.org, go@FreeBSD.org,
                    haskell@FreeBSD.org, java@FreeBSD.org,
                    kde@FreeBSD.org, olgeni@FreeBSD.org, perl@FreeBSD.org,
                    ports-bugs@FreeBSD.org, python@FreeBSD.org,
                    ruby@FreeBSD.org, rust@FreeBSD.org, x11@FreeBSD.org
            Blocks: 272216
             Flags: exp-run?

Created attachment 247801
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247801&action=edit
patch

Both our make and gmake use the MAKEFLAGS environment variable but the values
aren't compatible and the latest version of gmake complains about that.  To
prevent that environment variables interfere with the build process like this,
this patch adds a new command SETENVI=/usr/bin/env -i that clears the
environment.  The idea is to use SETENVI instead of SETENV when running build
tools and scripts so their environment only contains variables from
CONFIGURE_ENV or MAKE_ENV or TEST_ENV or similar.  This way it doesn't matter
what variables our make uses or what environment variables a user might have
set.

This patch takes care of Mk/* and Mk/Uses/*.  Individual ports can be changed
later.

If you are the maintainer of any of the Mk/Uses/* files please review the
changes.

A minor open problem is that the TERM environment variable is now missing which
means that error messages are no longer colored for instance.  I'd like to
introduce a new variable WRK_ENV that would contain common environment
variables like TERM, PATH, and SHELL, and perhaps other variables that are
common between CONFIGURE_ENV and MAKE_ENV.  It would be used in every make
target while CONFIGURE_ENV, MAKE_ENV, and TEST_ENV contain target specific
environment variables.  Any objections to this?


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272216
[Bug 272216] devel/gmake: Update to 4.4.1
-- 
You are receiving this mail because:
You are on the CC list for the bug.