incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Pevtsov <ant...@moscow.vdiweb.com>
Subject Re: [Re: [Fwd: Solution generartion script for Intel 9.0 compiler]]
Date Thu, 22 Dec 2005 15:32:42 GMT
Martin Sebor wrote:

>>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?
>  
>

Yes, see the description below, please.

I attached the patch for the current SVN version, but because almost all
files were changed you might replace the existing files using comments
below and not apply the patches.

The attached archive contains two script patch files (scripts1.diff and
scripts2.diff) and two new script files (icc_config.js and 
icc-config_classes.js). Apply scripts1.diff first, and then
scripts2.diff to avoid conflicts, please.

ChangeLog entry:

2005-12-22  Anton Pevtsov  <antonp@moscow.vdiweb.com>

* config.js:
Added library directories collection into the Linker "class"

* configure.wsf:
corrected helper xml comments, updated error hadling - the script 
tells the user where to look for the log file. Added option for the
icc-9.0 Defines to avoid problems with '*' symbol in 19 package version
of the 
Intel 9.0 C++ compiler, function tests updated correspondingly

* data.js:
The solution names were moved to this file to be used in all other 
script files.

* fun_present_check.cpp
Added FUN_PARAMS helper define to avoid problem with Compilation for
Intel 9.0 C++ 19 package '*' problem workaround.

* generate.js
Added icc-specific functions for the solution generation, added
checkEnvironment function for all configurations (it checks that 
all utilities required for the solution generation are available),
implemented generateSolution method for icc (msvc implementation 
updated), added helper functions for the source files filters.

* generate.wsf
corrected helper xml comments, updated builddir variable to use config
in the directory name, added checkEnvironment step to 
the solution generation workflow, modified the final output, updated
generateBuildBatch function to be config-independet and accept the
config as first parameter, the same for the 
generateUpdateBatch function.

* makelog.wsf
corrected helper xml comments, added CONFIG script parameter, updated
the log file name generation mechanism to use the configrutation in the
file name

*runall.wsf
Fixed typo.

* summary.js
Added mechanism to read compilation output from BuildLog.html in
non-table data form, updated the BuildLog.html reading workflow, changed
the log file name generation function to use the configuration in the
log file name.

* update.wsf
corrected helper xml comments, added checkEnvironment step to 
the solution update workflow, added several icc-90 specific steps (i.e
converting from icc projects structure to msvc and vice versa).

* utilities.js
Added converSolutionImpl function for the solution conversion fo or from
Intel projects structure, added special processing for the solutions
which has cpecific configurations for the configure project (icc).

* msvc-config.js
Added the icc-9.0 solution creation as copy of msvc-7.1 solution. It is
here to 
be sure that icc solution will be created after msvc-7.1 creation and
configuration. all configure tools functions made configuration
independent (they receive all necessary information via parameters).
configureToolsVC71 changed 
correspondingly.

* msvc-config_classes.js
Added processing for the additional libraries in linker.


New files:

* icc-config.js
Contains "classes" for the icc-9.0 compiler, linker, librarian, etc.

*icc-config_classes.js
Contains the icc9.0_config solution tools configuration. This special
solution is used for configure project compilation instead of icc-9.0.
Should be included to configure.wsf script only.


With best wishes, 
Anton Pevtsov


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Wednesday, December 21, 2005 22:34
To: stdcxx-dev@incubator.apache.org
Subject: Re: [Fwd: Solution generartion script for Intel 9.0 compiler]


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?

Martin


Mime
View raw message