Re: toolchain target

On 18/06/2015 09:22, Andriy Gapon wrote:
> My make.conf:
> .if defined(CC)
> .if ${CC} == gcc
> CPUTYPE?=k8-sse3
> .else
> CPUTYPE?=amdfam10
> .endif
> .endif
> CFLAGS+= -O2 -fno-strict-aliasing -pipe
> CFLAGS+= -fno-omit-frame-pointer
> CXXFLAGS+= -O2 -fno-strict-aliasing -pipe
> 
[snip]
> Looks like my rather innocent manipulations of CFLAGS could be causing the problem.
> Without my make.conf:
> mkdep -f .depend -a
> -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/include
> -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
> -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
> -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
> -I/usr/obj/usr/devel/svn2/head/tmp/legacy/usr/include  -std=c++11
> -stdlib=libc++
> /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp
> ...
> 
> With my make.conf:
> mkdep -f .depend -a      -std=c++11  -stdlib=libc++
> /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp
> ...
> 
> All the preprocessor flags (-I, -D) are gone.
> 

Or rather it's CXXFLAGS that is affected.
Looks like now in my environment the initial value of CXXFLAGS is set by
make.conf instead of being derived from CFLAGS in mk/sys.mk.  This breaks
expectation of many makefiles that flags added to CFLAGS will also be appear in
CXXFLAGS.
Apparently, this problem is documented in UPDATING 20150616, but it does not
cover all possible variables affected by the change...

So, I guess that I could just remove CXXFLAGS from my make.conf, because it is
quite redundant, but in some cases people may still want to set it.
Or I could copy the CXXFLAGS assignment line from mk/sys.mk to make.conf, but
that's a slippery slope towards having to copy all of mk/sys.mk to make.conf.
Or maybe the historic behavior could be restored and whatever prompted the
change could be done in a different fashion?

-- 
Andriy Gapon