On Jun 16, 2011, at 11:57 PM, "b. f." <bf1...@googlemail.com> wrote:
> On 6/17/11, Sahil Tandon <sa...@freebsd.org> wrote: >> On Thu, 2011-06-16 at 16:47:33 +0000, Alexey Dokuchaev wrote: >> >>> On Thu, Jun 16, 2011 at 08:42:28AM +0000, Wen Heping wrote: >>>> wen 2011-06-16 08:42:28 UTC >>>> >>>> Modified files: >>>> sysutils/tmux Makefile >>>> Log: >>>> - Fix build when CFLAGS is set in /etc/make.conf >>> >>> Hmm, default CPPFLAGS is empty. Judging just from the diff, instead of >>> introducing EXTRA_CPPFLAGS, setting CPPFLAGS instead of CFLAGS (which is >>> bogus in the first place: -I is preprocessor flag) should be enough (no >>> MAKE_ENV adjustment and extra REINPLACE_CMD hack would be required in this >>> case as well). I am missing something obvious here? >> >> Because of the way upstream Makefile handles CPPFLAGS, it is not so >> straightforward. This was discussed on freebsd-ports: >> >> http://lists.freebsd.org/pipermail/freebsd-ports/2011-June/068218.html >> http://lists.freebsd.org/pipermail/freebsd-ports/2011-May/067930.html > > But this does not seem so different from the many other ports that set > or alter variables in the port Makefile. If a user overrides these > changes in an automatically and recursively-included Makefile like > __MAKE_CONF, or on the command-line, it it the user's problem. Users > should not pollute their port builds by unconditionally defining > variables in __MAKE_CONF, and I don't think that we should add > elaborations to ports to avoid such mistakes. Yes and I think we get that and I personally agree with your sentiment; however, I'm not sure that means maintainers need to revert commits that were done to prevent users from shooting their own foot._______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscr...@freebsd.org"
