Farid Zaripov wrote:
I wonder if it wouldn't be cleaner to move all the Intel C++ specific code out of _config-msvc.h and into _config-icc.h and make sure we #include the former only for MSVC and the latter only for Intel C++. One of the goals of separating all the compiler-specific hacks and overrides was to make it clear what's where and avoid accidentally breaking one compiler while fixing a problem in another. The way we handle MSVC and Intel C++ on Windows seems to go against the goal (even though the compilers are meant to be fully compatible).

Thoughts?

  The Intel C++ compiler is just set of the binary tools (compiler,
linker, .... and some
processor optimized extension libraries (math library, integer and float
vector class library).
The package don't include the CRT library and uses the CRT from
installed MSVC.
I have the installed three versions of the MSVC: 7.0, 7.1 and 8.0. And I
can build
the some project using Intel C++ with any CRT which I have.

  I mean that some of the macros from _config-msvc.h is not
compiler-specific, but CRT specific.

Right, good point. We don't make a distinction between compilers
and their runtime libraries. I don't think Intel C++ on Windows
is the only compiler that uses (parts of) another compiler's
runtime. AFAIK, IBM XLC++ on Linux works the same way (uses
gcc's runtime). I suspect there might be, or will be, others,
such as Sun C++ when Sun implements and deploys its gcc
compatibility mode. See Steve Clamage's comment in this thread:
http://forum.java.sun.com/thread.jspa?threadID=5173584

If we want to separate the Intel and MSVC config files, we should
copy-paste that
macros into the _config_icc.h. Is that corresponds the goals?

Well, I guess we need to decide if it's a good idea to maintain
two sets of the same chunks of code or if it would be better to
factor the code into a common file. If the latter, we need to
decide on the mechanism we want to use to use the code with each
compiler. Here are the possibilities I see:

1. Status quo: For an Intel C++ installation on top of MSVC
_config.h #includes both _config-msvc.h and _config-icc.h,
and _config-msvc.h must be prepared to deal with it.

2. Duplicate CRT-specific macro hackery from _config-msvc.h
in _config-icc.h for Intel C++ on top of MSVC.

3. Move CRT-specific macros hackery from _config-msvc.h to
a new config header, say _config-msvcrt.h, and #include this
header from both _config-msvc.h and _config-icc.h, making
sure _config-msvc.h is #included only for MSVC and not for
Intel C++ on top of it.

Preferences? Any other possible ways to deal with this?

Martin

Reply via email to