Re: [PR] avoid overriding external prefix

[Илья Шипицин]

2018-01-04 2:13 GMT+05:00 Willy Tarreau :

> Hi Stephen,
>
> On Wed, Jan 03, 2018 at 08:33:14PM +0100, PR Bot wrote:
> > Dear list!
> >
> > Author: Stephen 
> > Number of patches: 1
> >
> > This is an automated relay of the Github pull request:
> >avoid overriding external prefix
> >
> > Patch title(s):
> >avoid overriding external prefix
> >
> > Link:
> >https://github.com/haproxy/haproxy/pull/82
>
> From d14f3c9d806bfe6e6b7e1fb81ab9973b04d2736a Mon Sep 17 00:00:00 2001
> From: Stephen 
> Date: Wed, 3 Jan 2018 09:28:35 -0800
> Subject: [PATCH] avoid overriding external prefix
>
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 8927919b..755503d4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -91,7 +91,7 @@
>
>   Installation options.
>  DESTDIR =
> -PREFIX = /usr/local
> +PREFIX ?= /usr/local
>  SBINDIR = $(PREFIX)/sbin
>  MANDIR = $(PREFIX)/share/man
>  DOCDIR = $(PREFIX)/doc/haproxy
>
> I'm wondering why it is that over the last few weeks we received a few
> such wrong patches while we never had them in 15 years. Maybe we need
> to add a few lines to the makefile explaining how to use a makefile and
> why it's *always* wrong to use "?=" (it inherits whatever randomly lies
> in your environment).
>

if it is wrong, why is it used almost everywhere :)

# find . -name Makefile -exec grep '?=' {} ';' -print
CC ?= gcc
./Makefile
CC   ?= gcc
./contrib/tcploop/Makefile
CC   ?= gcc
./contrib/iprange/Makefile
CC ?= gcc
CXX ?= g++
./contrib/mod_defender/Makefile
CC ?= gcc
./contrib/spoa_example/Makefile
CC  ?= gcc
./contrib/debug/Makefile
CC   ?= gcc
./contrib/halog/Makefile
CC ?= gcc
./contrib/modsecurity/Makefile
CC   ?= gcc
./contrib/ip6range/Makefile




>
> Please have a look at the longer explanation I sent here a few days ago :
>
>https://www.mail-archive.com/haproxy@formilux.org/msg28390.html
>
> Thanks,
> Willy
>
>

Re: [PR] avoid overriding external prefix

[Willy Tarreau]

Hi Stephen,

On Wed, Jan 03, 2018 at 08:33:14PM +0100, PR Bot wrote:
> Dear list!
> 
> Author: Stephen 
> Number of patches: 1
> 
> This is an automated relay of the Github pull request:
>avoid overriding external prefix
> 
> Patch title(s): 
>avoid overriding external prefix
> 
> Link:
>https://github.com/haproxy/haproxy/pull/82

>From d14f3c9d806bfe6e6b7e1fb81ab9973b04d2736a Mon Sep 17 00:00:00 2001
From: Stephen 
Date: Wed, 3 Jan 2018 09:28:35 -0800
Subject: [PATCH] avoid overriding external prefix

---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 8927919b..755503d4 100644
--- a/Makefile
+++ b/Makefile
@@ -91,7 +91,7 @@
 
  Installation options.
 DESTDIR =
-PREFIX = /usr/local
+PREFIX ?= /usr/local
 SBINDIR = $(PREFIX)/sbin
 MANDIR = $(PREFIX)/share/man
 DOCDIR = $(PREFIX)/doc/haproxy

I'm wondering why it is that over the last few weeks we received a few
such wrong patches while we never had them in 15 years. Maybe we need
to add a few lines to the makefile explaining how to use a makefile and
why it's *always* wrong to use "?=" (it inherits whatever randomly lies
in your environment).

Please have a look at the longer explanation I sent here a few days ago :

   https://www.mail-archive.com/haproxy@formilux.org/msg28390.html

Thanks,
Willy

[PR] avoid overriding external prefix

[PR Bot]

Dear list!

Author: Stephen 
Number of patches: 1

This is an automated relay of the Github pull request:
   avoid overriding external prefix

Patch title(s): 
   avoid overriding external prefix

Link:
   https://github.com/haproxy/haproxy/pull/82

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/82.patch && vi 82.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/82.patch | git am -

Description:


Instructions:
   This github pull request will be closed automatically; patch should be
   reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is
   invited to comment, even the patch's author. Please keep the author and
   list CCed in replies. Please note that in absence of any response this
   pull request will be lost.