RE: icl /D problem (was Re: Solution generartion script for Intel 9.0 compiler)

2005-12-15 Thread Anton Pevtsov
The cause of the different issues is the the different versions of the Intel C++ 9.0 compiler. I have Intel(R) C++ Compiler for 32-bit applications, Version 9.0Build 20051020Z Package ID: W_CC_C_9.0.019 W_CC_C_9.0.019 compiler version has no problem with spaces in defines: /D

(.icproj files for Intel C++ on Windows) Re: Solution scripts for Intel C++ 9.0 Compiler

2005-12-15 Thread Martin Sebor
Anton Pevtsov wrote: [...] I found that there are several strange things with ICC Compiler integrated into Visual Studio: [...] 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

copying .dll to project directories (was Re: [Fwd: Solution generartion script for Intel 9.0 compiler])

2005-12-15 Thread Martin Sebor
Anton Pevtsov wrote: [...] Martin Sebor wrote: 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

makefile patch

2005-12-15 Thread Liviu Nicoara
Martin, Could you please take a look at this patch and let me know if it meets your approval? I have removed the all target, replaced it with a lib, which being first in the makefile is picked when building w/ no goals and configures and builds the library (no examples and/or tests which I

Re: makefile patch

2005-12-15 Thread Martin Sebor
Liviu Nicoara wrote: Martin, Could you please take a look at this patch and let me know if it meets your approval? Will do. But first a few things about the process :) 1. The subject line of a patch should start with the string [PATCH] to make it easily distinguishable from other posts. 2.

Re: makefile patch

2005-12-15 Thread Liviu Nicoara
Martin Sebor wrote: Liviu Nicoara wrote: But first a few things about the process :) Will follow. That looks okay. I'm just not too excited about the duplication if the code between lib and .DEFAULT. Is there an easy way to avoid it? Not excited about that either. I spent some time

Re: makefile patch

2005-12-15 Thread Liviu Nicoara
I think we had those at some point in the past. IIRC, I took them out because I thought it was cleaner to have them in the individual (sub) makefiles instead. I.e., the top level makefile shouldn't need to know all the dependencies of each subcomponent. It easy to miss some (such as the dependency

Re: makefile patch

2005-12-15 Thread Martin Sebor
Liviu Nicoara wrote: I think we had those at some point in the past. IIRC, I took them out because I thought it was cleaner to have them in the individual (sub) makefiles instead. I.e., the top level makefile shouldn't need to know all the dependencies of each subcomponent. It easy to miss some

Re: makefile patch

2005-12-15 Thread Martin Sebor
Liviu Nicoara wrote: Martin Sebor wrote: Liviu Nicoara wrote: I think we had those at some point in the past. IIRC, I took them out because I thought it was cleaner to have them in the individual (sub) makefiles instead. I.e., the top level makefile shouldn't need to know all the

[PATCH] build process fails in TOPDIR if target (lib, etc.) specified (was Re: makefile patch)

2005-12-15 Thread Liviu Nicoara
Addressing: http://issues.apache.org/jira/browse/STDCXX-85 ChangeLog entry: 2005-12-15 Liviu Nicoara [EMAIL PROTECTED] * GNUMakefile: removed useless rules: all, builddir, added rule lib, added variable INCDIR * etc/config/GNUmakefile.lib: invoked make config when