| Yes they are, but the configure script still looks for a compiler if CC/CXX
| is not defined, leading to some assumptions for the configure tests. After
| some more checks, this should not be a problem, but still this is not "clean".
| Here's for instance what happens with the "image" package:
| - ./configure looks for a compiler in the following order: gcc, cc, cl
| - it finds cl (gcc is not in the PATH or not installed); hence the default
| object suffix is set to .obj
| - testing for a header like jpeglib.h tests its presence and usability;
presence
| is OK, but usability is not: this is due to the fact that ./configure
| script tries
| to compile a file and test for the object file existence; at that
| point, CC has been
| redefined to cc-msvc (with "mkoctfile -p CC"), which by default produces .o
| object file; but the configure script looks for a .obj file and the
| test fails, leading
| to this kind of warning
|
| configure: WARNING: jpeglib.h: present but cannot be compiled
| configure: WARNING: jpeglib.h: check for missing prerequisite headers?
| configure: WARNING: jpeglib.h: proceeding with the preprocessor's result
| configure: WARNING: ## ------------------------------------ ##
| configure: WARNING: ## Report this to address@hidden ##
| configure: WARNING: ## ------------------------------------ ##
OK, how do you want to solve this problem?
BTW, the recommended way to run configure and set variables like CC,
CXX, etc. is
./configure CC=... CXX=...
Couldn't every invocation of configure that happens when building
Octave Forge packages use something like
./configure CC=$(mkoctfile -p CC) CFLAGS=$(mkoctfile -p CFLAGS) ...
? Wouldn't this work on all systems, and shouldn't this be the
preferred way anyway so that the compiler used for building the
package is the same as was used for building Octave?