notbugAs an Amazon Associate I earn from qualifying purchases.
Want a good read? Try FreeBSD Mastery: Jails (IT Mastery Book 15)
Want a good monitor light? See my photosAll times are UTC
Ukraine
This referral link gives you 10% off a Fastmail.com account and gives me a discount on my Fastmail account.

Get notified when packages are built

A new feature has been added. FreshPorts already tracks package built by the FreeBSD project. This information is displayed on each port page. You can now get an email when FreshPorts notices a new package is available for something on one of your watch lists. However, you must opt into that. Click on Report Subscriptions on the right, and New Package Notification box, and click on Update.

Finally, under Watch Lists, click on ABI Package Subscriptions to select your ABI (e.g. FreeBSD:14:amd64) & package set (latest/quarterly) combination for a given watch list. This is what FreshPorts will look for.

non port: x11-wm/golem/files/patch-Makefile.rules.gnu.in

Number of commits found: 2

Monday, 19 Oct 2015
15:05 danfe search for other commits by this committer
Get rid of hand-rolled `do-build' and `do-install' targets which serve the
sole purpose to avoid using our standard MAKE_ENV.

They were introduced in r279589 as part of "update to 0.0.6" PR 159499 by
Kato (duh!) some four years ago; in r359185 bapt@ had mentioned that "lots
of invocation of MAKE_CMD here are wrong as they do not properly respect
MAKE_ENV" (which is ironic as avoiding MAKE_ENV *is* their only point) but
the the real problem was neither fixed nor rationale for ugly work-around
explained.

The port builds itself through a series of recursive make(1) calls, and is
using variables to pass various bits of internal state to submakes.  This
approach typically requires strict discipline and can be hard to implement
correctly, to an extent being considered harmful [Miller 1997].

Incidentally, ${MAKE_ENV} includes variables that are 1) used by the port's
own build logic and 2) are not handled in a robust way by it.

Problem #1: consider the following code from `Makefile.rules.gnu.in':

  ifndef LIBDIR
    LIBDIR=.
  endif

This is roughly equivalent to the following:

  ifeq ($(origin LIBDIR), undefined)
    LIBDIR=.
  else
    # use whatever LIBDIR value make(1) can deduce
  endif

Knowing that LIBDIR is set to some other value (`..') by inner makefiles,
that code can be rewritten more elaborately like this:

  ifeq ($(origin LIBDIR), undefined)
    LIBDIR=.
  else ifeq ($(origin LIBDIR), file)
    # use LIBDIR value set by some Makefile
  else
    # use whatever LIBDIR value make(1) can deduce
  endif

Now, because LIBDIR is passed to make(1) via MAKE_ENV and the code above
does not have "ifeq ($(origin LIBDIR), environment)" check, the build was
affected by unexpected bogus value of it and subsequently failed.  Since
the only valid place we can expect "our" LIBDIR to come from is makefiles,
we can inhibit unwanted pollution from the environment by rewriting the
initial code like this:

  ifneq ($(origin LIBDIR), file)
    LIBDIR=.
  endif

Problem #2 is similar: checking for CFLAGS and LDFLAGS to protect their
initial assignment is very fragile as many frameworks akin to the Ports
Collection would provide some default values.  While it is usually safe
to append to them, it is almost always a bad idea to use them verbatim.

Apparently, these checks were put there to support resetting CFLAGS and
LDFLAGS in `util/Makefile', but since removing them does not hurt do so
regardless of small pollution in that one case that does not affect the
build in any noticeable way.
Original commitRevision:399689 
Thursday, 23 Jan 2014
03:06 vanilla search for other commits by this committer
Support STAGEDIR.

Approved by:	portmgr (blanket infrastructure)
Original commitRevision:340775 

Number of commits found: 2