This looks like a fine change to me, but I do wonder about Spack's ability to handle this sort of thing automatically. It was my understanding that Spack used environment variables like CC, CXX, and PATH to ensure that its configured compilers would be used to build its targeted packages. For example, I found the following snippets while using a non-standard GCC to build a version of ffmpeg without these changes:

ffmpeg-stage/spack-build-env.txt

CC=/path/to/spack/env/gcc/gcc
CXX=/path/to/spack/env/gcc/g++
PATH=/path/to/spack/env/gcc/gcc:...

ffmpeg-stage/spack-src/config.mak

CC_IDENT=gcc 8.1.0 (GCC)   # non-standard GCC properly detected
CC=gcc                     # will use [email protected] due to current PATH
CXX=g++                    # will use [email protected] due to current PATH

With all of this being the case, I'm not sure that these changes are necessary. @tkameyama: Did you find that you needed these changes in order to build with a certain compiler on your systems? If not, I think we should keep the package as it is now because this logic looks to be handled by Spack's internal mechanisms.

This looks like a fine change to me, but I do wonder about Spack's ability to handle this sort of thing automatically. It was my understanding that Spack used environment variables like CC, CXX, and PATH to ensure that its configured compilers would be used to build its targeted packages. For example, I found the following snippets while using a non-standard GCC to build a version of ffmpeg without these changes:

ffmpegb is not use autoconf.
Insted of ffmpeg is used own configure script.
And the configure script dose not use CC environment variable:

[kameyama@kameyamapc2c spack-src]$ pwd
/work/tmp/pytest-of-kameyama/spack-stage-ffmpeg-4.2.2-xrscz4glvrgco4cveykx5sj3iotcktuj/spack-src
[kameyama@kameyamapc2c spack-src]$ grep -w CC configure
  --cc=CC                  use C compiler CC [$cc_default]
set_ccvars CC
CC=$cc

Default compiler is gcc.
If we change compiler, we must use -cc option or --toolchain option.

With all of this being the case, I'm not sure that these changes are necessary. @tkameyama: Did you find that you needed these changes in order to build with a certain compiler on your systems? If not, I think we should keep the package as it is now because this logic looks to be handled by Spack's internal mechanisms.

I check Fujitsu compiler:
spack install ffmpeg%fj
But the configure is used gcc.

I just tested a non-GCC build (i.e. [email protected]%[email protected]) and I can confirm the behavior that you're seeing regarding improper gcc preference. Here are the same files I referenced above in my new test configuration:

ffmpeg-stage/spack-build-env.txt

CC=/path/to/spack/env/clang/clang
CXX=/path/to/spack/env/clang/clang++
PATH=/path/to/spack/env/clang:...

ffmpeg-stage/spack-src/ffbuild/config.mak

CC_IDENT=gcc 4.9.3 (GCC)   # wrong! where is "clang"?
CC=gcc                     # will use [email protected]
CXX=g++                    # will use [email protected]

Thus, I can see why these changes are necessary even with Spack's automatic environment handling. Thanks for humoring these questions and for this submission!

Also @alalazo: I feel like I'm familiar enough with this package at this point to serve competently as a maintainer, so I'll volunteer to fill that slot should it still be open.

I feel like I'm familiar enough with this package at this point to serve competently as a maintainer, so I'll volunteer to fill that slot should it still be open.

Thanks @xjrc If you submit a PR in that sense I'll merge it straight away.