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 Thu, 15 Dec 2005 01:50:26 GMT
Martin Sebor wrote:
> -------- Original Message --------
> Subject: Solution generartion script for Intel 9.0 compiler
> Date: Wed, 14 Dec 2005 19:42:45 +0300
> From: Anton Pevtsov <>
> [...]
> Hi Martin,
> The attached archive ( contains the latest version of
> the solution generation scripts. Now it supports the solution and build
> summary log generation for the Intel 9.0 compiler. The script operates
> in the following way: it generates the VC solution and converts it to IC
> solution using the ICProjConvert90 utility (it is installed with the
> Intel compiler).

How do I get it to do the conversion? (I.e., how should I invoke
it to get it to do that?) I launched it the usual way and all I
got was a VisualStudio solution. Btw., the solution ended up in
a subdirectory of the directory I specified instead of directly
in BUILDDIR as before. I assume that's a bug?

> I suppose that the user added paths to Intel directories

You mean you /assume/ that in your code. Since we assume the same
to be true for MSVC that's a reasonable assumption to make.

> (and to
> ICProjConvert90.exe utility which is located in Common Files folder in
> Program Files) to PATHS environment variable. Also it is necessary to
> add paths to IC folders into Visual Studio general directories
> (Tools/Options Projects tabs, VC++ directories) to build from Visual
> Studio.

You mean they actually have to edit the paths themselves? Unless
that's part of the Intel C++ installation (and integration with
Visual Studio) we should do this for them.

> And I suppose that the user executed vsvars32 before the calling
> to build.bat.

That's also a reasonable assumption.

> The solution update script will be added in next version.
> The attached archive contains the build summary log for
> Intel C++ 9.0 compiler.
> There are a couple of questions (they were asked in my previous e-mails,
> but I repeat them here):
> 1) Shall we have build.bat for each configuration (VC71, ICC90)...

Answered separately.

> 2) Where shall we store the build summary log? The build summary log
> files have config-specific names, so we can store them in BUILDDIR\type
> (for example, $(BUILDDIR)\11d) directories or in BUILDDIR\config
> directories (for example $(BUILDDIR)\icc-9.0); both variants are
> possible. Currently I change nothing here and build summary log files
> are stored in BUILDDIR\config directories.

A good place for the log is directly in BUILDDIR. E.g.,




Btw., it would be good to use the same naming convention we agreed
on consistently for all files (IIRC, for the logs it would be
<compiler>-<version>-<buildtype>.html -- let's also use the .html
suffix instead of .htm if possible).

Also, what did we say we'd do with the library? Put it in a compiler
specific subdirectory under BUILDDIR/lib? We need to start documenting

> And there are several issues for Intel C++ 9.0 Compiler (they were in my
> previous e-mails too):
> 1) The absolute paths to the projects in the solution file are not
> supported when you use ICC projects tree. I changed scripts to generate
> relative paths but if we need to keep absolute paths for MSVC I'll
> branch the script code to MSVC and ICC versions.

I'm not sure I understand what exactly this means. Absolute paths
to the stdcxx sources? Or just the .vcproj files? If the former I'm
not sure I see how we could use the same solution for both MSVC and
Intel C++ if the have incompatible requirements on pathnames. If
the latter, as long as MSVC and VisualStudio can deal with relative
pathnames I don't see a problem using them. If you think it's a bug
or limitation in the Intel C++ integration feature with VisualStudio
it would be good to create a test case and open a problem report with
Intel to make sure they fix it (I can file it if you don't have
access to their support site).

> 2) The ICC solutiion uses .icproj files for projects but requires
> corresponding .vcproj files too. It looks like it is impossible to open
> the solution without .vcproj file. So the builddir for ICC90 contains
> both .icproj and .vcproj files.
> 3) The Intel Compiler doesn't allow the '*' symbol in defines...

Answered separately.

> 4) There is a problem with project dependencies. They present in the
> solution file and you can see them in Visual Studio but it looks like
> they are ignored in the building process. This results in that all
> examples could not be build because of linker errors. But I can
> sucessfully  link any example manually from the command line providing
> paths to the required libraries.
> After investigation I decided to store paths to the libraries in the
> project files. These changes don't affect MSVC version.

That's seems okay, but again, if it's an Intel bug or limitation we
should open an issue.

Also, if we are still copying the .dll to the example and test
directories as I noticed the script was some time back I would like
to change this to make sure no such copying takes place. Instead we
should modify the PATH variable or do whatever else is normally done
within the IDE to get this to work.

> The archive contains .diff files for each modified
> script file and two new files:
> icc-config.js        (Solution configuration code for Intel compiler)
> icc-config_classes.js     (Intel Compiler, Linker, Librarian tools
> "classes")
> I plan to modify the update script, implement your notes (see questions
> above, please) if any, and send the scripts patches to stdcxx-dev.

Okay. I won't apply this patch then and instead wait for a new one.
Please make sure your patch can be successfully applied using the
patch utility before sending it -- thanks!

> And
> there is a question: shall I send one patch file with all my changes in
> scripts (it will be large) or it will be more convenient to send small
> patch for each script (like in the attached archive) ?

I forwarded your email and attached the expanded patch as a single
file to it. I think it's fine to simply send a single patch like I
did as long as it can be applied using the patch utility (we should
test it first which I didn't with this one). You might just want to
send new files as separate attachments.

In addition, when sending a patch that you think is ready to be
applied you need to also send your changelog entry describing the
changes (see one of the ChangeLog entries for an example, e.g., Unless
the patch is trivial or self-explanatory you should also describe
why it's useful and any potential issues you expect with it (i.e.,
what you said in your email).


View raw message