stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: [Fwd: Solution generartion script for Intel 9.0 compiler]
Date Wed, 21 Dec 2005 02:52:54 GMT
Anton Pevtsov wrote:
> Martin Sebor wrote:
> [...]
>>I'm not sure where to look for more details. It would be useful to
> display the command line that failed and the actual error, just like
> the GNU makefile infrastructure does (I encourage you to try   > to
> invoke it without a compiler in your path or with the wrong compiler to
> see how it behaves).
> Yes, the message misses the information about where to look for the
> config.log file. This file contains all commands executed during the
> config.h building. I'll update the configure.wsf script error messages
> and they will tell the user where to look for the log.

Another annoying problem when this happens is that the build actually
proceeds with the library even after the configuration fails, generating
hundreds of lines of output. It would be more user-friendly for the
build to abort when configure fails to generate the config header.

Btw., while trying to get this to work I left the log file opened in
another terminal window and tried to another build. It crapped out
with an error complaining that it cannot write to the log file. Isn't
it annoying how Windows doesn't let you overwrite or remove a file
that's open by another process? I wish we could avoid these types
of errors -- any idea how to make Windows behave more reasonably?

> Currently the log is generated here:
> $(BUILDDIR)\$(CONFIG)\inculde\<build type>\config.log

Aah, yes I see it, thanks!

> I think the cause of your problem is that intel compiler (icl.exe)
> couldn't be found.

Yep, that's it. The log ends with:

'icl' is not recognized as an internal or external command,
operable program or batch file.

> "devenv" uses IDE paths to VC++ dirs and it looks
> like 
> the Intel Compiler installation didn't not set paths to Intel
> directories. There should be $(ICInstallDir)Bin n the IDE VC++
> Directories list (Tools->Options->Projects->VC++ Directories) for
> executable files, $(ICInstallDir)Lib for library files and
> $(ICInstallDir)Include for include files. If they are absent add them
> manually and try to build the solution, please.

I see Tools->Options, but no Projects under there. I do see a folder
titled Intel(R) C++ in the left pane of the box with three entries
in it:
     Intel(R) C++ 8.1
     Intel(R) C++ 9.0

There are paths on the right, some of them relative to what looks
like an environment variable: $(ICInstallDIr). There is no slash
between the variable and the next component (e.g., there is
$(ICInstallDIr)Bin when I would expect $(ICInstallDIr)\Bin). But
there is also the verbatim path to the Intel compiler, right after
$(ICInstallDIr)\Bin. (I also tried defining the variable on the
command line and restarting VisualStudio -- I still get the same

> The Visual Studio IDE paths are stored in the VCComponents.dat file
> which is situated in Documents and Settings\<User name>\Local
> Settings\Application Data\Microsoft\VisualStudio\7.1 folder.
> I see the following ways to solve this problem with paths:
> 1. Add the paths requirements to the prerequisites: the user should add
> paths to IDE VC++ Dirs before the building.

This should be done for them by the Intel C++ integration. There
clearly is a lot of stuff in there for icc so this seems like an
essential requirement.

> 2. Modify VCComponents.dat file from the script. This seems to be
> tricky. 

I don't even know what VCComponents.dat is... Unless it's our file
I wouldn't touch it.

> 3. Build the soltuion using the /useenv switch. This will work for Intel
> but will not work for MSVC, so it will be necessary to add some "if"
> into the build.bat file.

Whose switch is this? Ours or someone else's?

> I think that we may try to implement the third option but keep in mind
> the first one. Also, some "readme" document (with prerequsites and logs
> description) may be helpful. 
> What do you think about it?

I don't know yet. I still don't understand what's going on. But of
the three options above, 3 sounds the best. That is, unless there
is an even easier way (such as getting the Intel C++ integration
to do it for us, in which case 1 would be even better.)

Gotta go now. I'll try to get it work tomorrow (hopefully you'll
have some insight in the meantime :)


View raw message