Hi David, On Wed, Dec 27, 2017 at 01:23:34PM +0000, David CARLIER wrote: > diff --git a/contrib/spoa_example/Makefile b/contrib/spoa_example/Makefile > index c44c2b879..71ba6107a 100644 > --- a/contrib/spoa_example/Makefile > +++ b/contrib/spoa_example/Makefile > @@ -2,12 +2,14 @@ DESTDIR = > PREFIX = /usr/local > BINDIR = $(PREFIX)/bin > > -CC = gcc > +CC ?= gcc
Please don't use "?=". It will inherit stuff from the environment, leading to all sort of surprizes. Instead "=" is easily overriden on the command line. Example : $ CC=foo make will always use "gcc" when the rule says "CC = gcc" but will use "foo" when the rule uses "CC ?= gcc". But : $ make CC=foo will always use "foo" regardless of how you write your rule. If you explicitly want to force using "$CC" in your case because you do have such a variable in your environment that you prefer, you can easily do it this way : $ make CC=$CC While it may not seem obvious for a variable such as CC that it's bad to have Make automatically inherit random variables, it becomes much more visible when you simply type "env" on your shell after a day of work and figure the number of things you've added for a temporary usage that you forgot to unset and that you'd never want your makefile to automatically use! And it's even worse when you make from a script which may sometimes set CFLAGS or stuff like this for certain components. So it's a good practice to isolate makefiles against accidental use of environment variables. Some projects have gone to great lengths doing this, e.g. to avoid randomly breaking complex build setups (like CFLAGS silently being passed through older versions of gcc+glibc+binutils build sessions, randomly breaking toolchain utilities, sometimes requiring to build several times in a row just to get rid of the issue). > CFLAGS = -g -O2 -Wall -Werror -pthread > -INCS += -I../../ebtree -I./include > -LIBS = -lpthread -levent -levent_pthreads > +INCS += -I../../ebtree -I./include -I$(PREFIX)/include > +LIBS = -lpthread -l$(EVENTLIB) -levent_pthreads -L$(PREFIX)/lib I'm suspecting we may get into new trouble here due to the fact that it becomes impossible to remove this one when not relevant. For example on some systems you have to use $PREFIX/lib64. On other systems, no single $PREFIX will be valid and you risk to get undesired stuff. Also when cross-compiling, $PREFIX will point to your native system instead of the one in the toolchain. What exact build problem did you meet in your environment, and with what component ? Maybe we can find another way to deal with it. We could also imagine setting a set of FOOLIB and FOOINC variables to respectively specify the lib and include directories, properly taking care of the lib64 crap. > diff --git a/contrib/spoa_example/spoa.c b/contrib/spoa_example/spoa.c > index d8defd192..760ad9210 100644 > --- a/contrib/spoa_example/spoa.c > +++ b/contrib/spoa_example/spoa.c > @@ -53,7 +53,7 @@ > \ > gettimeofday(&now, NULL); \ > fprintf(stderr, "%ld.%06ld [%02d] " fmt "\n", \ > - now.tv_sec, now.tv_usec, (worker)->id, ##args); \ > + (long int)now.tv_sec, now.tv_usec, (worker)->id, > ##args); \ Good catch! Cheers, Willy
