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 19:34:01 GMT
Anton Pevtsov wrote:
> Martin, if the problems will remain with this version even if your
> system environment variables are set correctly, try to set IDE VC++
> directories from Visual Studio IDE as described below, please.

Thanks! Your changes resolved the original problem. Unfortunately,
a new one cropped up. See the attached config.log.

> you should add $(ICInstallDir)Bin,  $(ICInstallDir)Lib,
> $(ICInstallDir)Include to the directories list for executables, library
> and inculde files correspondingly.

Okay, adding $(ICInstallDir)Lib finally worked. Whew! Is there a way
to fix that? Btw., if we are adding these paths via our scripts we
should add a backslash in between $(ICInstallDir) and the directory
after it (Visual Studio seems to be aware of this and displays
the paths with the slash in bold).

> Martin Sebor wrote:
>  > 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.
> I am not sure that we can control the solution building in this way. As
> far as I know when Visual Studio builds a solution it is trying to build
> each project in the solution regardless of the build results.

What about avoiding trying to compile subsequent source files
of a project after the first compilation failure? Make (or even
nmake) does this by design.

> As far as I know it is impossible to recreate a file if it is opened for
> writing in another process. I think we may check in the begging that all
> log files could be created and stop with error if not. Or we can
> generate another log file with name <somelogname>1.log and continue with
> it.

That thought occurred to me, too. Let's ponder it for a while.

> I implemented option 3 : Build the soltuion using the /useenv switch.
> ("useenv" is devenv command line option).

Okay, thanks a lot! I still think that the Intel Visual Studio
integration tool should do this for us. If I'm motivated enough
I might open an issue with Intel for this.

Now that we have this resolved we can commit the changes. Anton,
could you please send a ChangeLog entry describing all the changes
you made?


View raw message