How to disable the check or the error after checking for ICU (for regex lib) when building boost ?
Hello I get the following message when compiling boost from trunk: 1>Building the Boost C++ Libraries. 1>has_icu_test.cpp 1>libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory 1>Performing configuration checks 1> - has_icu builds : no Although the build succeeds (as this is a test) Visual Studio recognizes the error in the output and stops compiling the project and reports the build as failed. Is there a way for me to suppress this message ? Or this test ? Attempting to redirect output with &>outfile.txt do not work as the error messages still gets output in VS. Are there and build options to disable this check ? Thank you, Timothy Madden
I get the following message when compiling boost from trunk:
1>Building the Boost C++ Libraries. 1>has_icu_test.cpp 1>libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory 1>Performing configuration checks 1> - has_icu builds : no
Although the build succeeds (as this is a test) Visual Studio recognizes the error in the output and stops compiling the project and reports the build as failed.
Is there a way for me to suppress this message ? Or this test ?
Attempting to redirect output with &>outfile.txt do not work as the error messages still gets output in VS. Are there and build options to disable this check ?
No not at present, unless they're present in Boost.Build somewhere. Actually I *never* see this error message just the Performing configuration checks - has_icu builds : no part. I'm not sure what controls this, but I'll try and find out. John.
John Maddock wrote:
I get the following message when compiling boost from trunk:
1>Building the Boost C++ Libraries. 1>has_icu_test.cpp 1>libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory 1>Performing configuration checks 1> - has_icu builds : no
Although the build succeeds (as this is a test) Visual Studio recognizes the error in the output and stops compiling the project and reports the build as failed.
Is there a way for me to suppress this message ? Or this test ?
Attempting to redirect output with &>outfile.txt do not work as the error messages still gets output in VS. Are there and build options to disable this check ?
No not at present, unless they're present in Boost.Build somewhere. Actually I *never* see this error message just the
Performing configuration checks - has_icu builds : no
part. I'm not sure what controls this, but I'll try and find out.
Please, it will help me prevent the build from stopping in VS. This happens on the trunk version of boost, from svn, the release tarball indeed does not display the message. Actually this only happens when building boost as a custom build step in my project's build process, from Visual Studio 2008. Building from the command line does not display the message. Which might make sense, since the message does not follow output redirection anyway. Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or sees some environment variables, and knows how to output the message ? Thank you, Timothy Madden
This happens on the trunk version of boost, from svn, the release tarball indeed does not display the message. Actually this only happens when building boost as a custom build step in my project's build process, from Visual Studio 2008. Building from the command line does not display the message. Which might make sense, since the message does not follow output redirection anyway.
Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or sees some environment variables, and knows how to output the message ?
Hmmm, no idea.... apparently you should never see the error messages - it's redirected to a log file. So it sounds like this could be a Visual Studio issue... John.
John Maddock wrote:
This happens on the trunk version of boost, from svn, the release tarball indeed does not display the message. Actually this only happens when building boost as a custom build step in my project's build process, from Visual Studio 2008. Building from the command line does not display the message. Which might make sense, since the message does not follow output redirection anyway.
Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or sees some environment variables, and knows how to output the message ?
Hmmm, no idea.... apparently you should never see the error messages - it's redirected to a log file. So it sounds like this could be a Visual Studio issue...
Just to clarify one detail above this thread -- is this issue happening only with trunk, and not with release (when both are built inside VS)? - Volodya
Vladimir Prus wrote:
John Maddock wrote:
This happens on the trunk version of boost, from svn, the release tarball indeed does not display the message. Actually this only happens when building boost as a custom build step in my project's build process, from Visual Studio 2008. Building from the command line does not display the message. Which might make sense, since the message does not follow output redirection anyway.
Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or sees some environment variables, and knows how to output the message ? Hmmm, no idea.... apparently you should never see the error messages - it's redirected to a log file. So it sounds like this could be a Visual Studio issue...
Just to clarify one detail above this thread -- is this issue happening only with trunk, and not with release (when both are built inside VS)?
Yes, indeed I tried it again to be sure. I unpack the release boost archive boost_1_43_0.tar.bz2, and build the boost libraries, all from a makefile, as a custom build step in my VS 2008 project, and boost compiles just fine. I unpack the archive with the trunk version of boost (at least as the trunk was a few days ago when I checked it out from svn) and build it in my project. Then I see the error in the Output window in VS 2008, and compilation of my project stops as the custom build step returned an error :(. You have the trimmed build logs attached. You can see a line: 1>libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory in the second build log (with the trunk version), after boostrapping bjam, but not in the first build log (with the release tarball). (including the entire build logs would make the message too large for this mailing list /newsgroup) Thank you, Timothy Madden
Timothy Madden wrote:
John Maddock wrote:
I get the following message when compiling boost from trunk:
1>Building the Boost C++ Libraries. 1>has_icu_test.cpp 1>libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory 1>Performing configuration checks 1> - has_icu builds : no
Although the build succeeds (as this is a test) Visual Studio recognizes the error in the output and stops compiling the project and reports the build as failed.
Is there a way for me to suppress this message ? Or this test ?
Attempting to redirect output with &>outfile.txt do not work as the error messages still gets output in VS. Are there and build options to disable this check ?
No not at present, unless they're present in Boost.Build somewhere. Actually I *never* see this error message just the
Performing configuration checks - has_icu builds : no
part. I'm not sure what controls this, but I'll try and find out.
Please, it will help me prevent the build from stopping in VS.
This happens on the trunk version of boost, from svn, the release tarball indeed does not display the message. Actually this only happens when building boost as a custom build step in my project's build process, from Visual Studio 2008. Building from the command line does not display the message. Which might make sense, since the message does not follow output redirection anyway.
Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or sees some environment variables, and knows how to output the message ?
Yes, it's watching for VS_UNICODE_OUTPUT environment variable. http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Thank you, Timothy Madden
On 8/16/2010 4:30 PM, Ilya Sokolov wrote:
Timothy Madden wrote:
John Maddock wrote:
I get the following message when compiling boost from trunk:
1>Building the Boost C++ Libraries. 1>has_icu_test.cpp 1>libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory 1>Performing configuration checks 1> - has_icu builds : no
Although the build succeeds (as this is a test) Visual Studio recognizes the error in the output and stops compiling the project and reports the build as failed.
Is there a way for me to suppress this message ? Or this test ?
Attempting to redirect output with &>outfile.txt do not work as the error messages still gets output in VS. Are there and build options to disable this check ?
No not at present, unless they're present in Boost.Build somewhere. Actually I *never* see this error message just the
Performing configuration checks - has_icu builds : no
part. I'm not sure what controls this, but I'll try and find out.
Please, it will help me prevent the build from stopping in VS.
This happens on the trunk version of boost, from svn, the release tarball indeed does not display the message. Actually this only happens when building boost as a custom build step in my project's build process, from Visual Studio 2008. Building from the command line does not display the message. Which might make sense, since the message does not follow output redirection anyway.
Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or sees some environment variables, and knows how to output the message ?
Yes, it's watching for VS_UNICODE_OUTPUT environment variable. http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Excelent ! I was still getting this problem with boost 1.44, so thank you for this information. Could boost better documented this somewhere ? Better yet, could the regex build process start by unsetting this variable ? Should I report this somewhere ? Thank you, Timothy Madden
Yes, it's watching for VS_UNICODE_OUTPUT environment variable. http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Excelent !
I was still getting this problem with boost 1.44, so thank you for this information. Could boost better documented this somewhere ?
Better yet, could the regex build process start by unsetting this variable ? Should I report this somewhere ?
Any change like that would have to be done inside Boost.Build somewhere, I guess file a ticket at svn.boost.org against Boost.Build if you want the change. HTH, John.
Timothy Madden wrote:
On 8/16/2010 4:30 PM, Ilya Sokolov wrote:
Timothy Madden wrote:
John Maddock wrote:
I get the following message when compiling boost from trunk:
1>Building the Boost C++ Libraries. 1>has_icu_test.cpp 1>libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory 1>Performing configuration checks 1> - has_icu builds : no
Although the build succeeds (as this is a test) Visual Studio recognizes the error in the output and stops compiling the project and reports the build as failed.
Is there a way for me to suppress this message ? Or this test ?
Attempting to redirect output with &>outfile.txt do not work as the error messages still gets output in VS. Are there and build options to disable this check ?
No not at present, unless they're present in Boost.Build somewhere. Actually I *never* see this error message just the
Performing configuration checks - has_icu builds : no
part. I'm not sure what controls this, but I'll try and find out.
Please, it will help me prevent the build from stopping in VS.
This happens on the trunk version of boost, from svn, the release tarball indeed does not display the message. Actually this only happens when building boost as a custom build step in my project's build process, from Visual Studio 2008. Building from the command line does not display the message. Which might make sense, since the message does not follow output redirection anyway.
Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or sees some environment variables, and knows how to output the message ?
Yes, it's watching for VS_UNICODE_OUTPUT environment variable. http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Excelent !
I was still getting this problem with boost 1.44, so thank you for this information. Could boost better documented this somewhere ?
Better yet, could the regex build process start by unsetting this variable ? Should I report this somewhere ?
Do you always get those messages, or only when building a fresh tree for the first time? - Volodya
On 02.09.2010 14:15, Vladimir Prus wrote:
Timothy Madden wrote:
On 8/16/2010 4:30 PM, Ilya Sokolov wrote:
Timothy Madden wrote:
John Maddock wrote:
I get the following message when compiling boost from trunk:
1>Building the Boost C++ Libraries. 1>has_icu_test.cpp 1>libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory 1>Performing configuration checks 1> - has_icu builds : no
Although the build succeeds (as this is a test) Visual Studio recognizes the error in the output and stops compiling the project and reports the build as failed.
Is there a way for me to suppress this message ? Or this test ?
Attempting to redirect output with&>outfile.txt do not work as the error messages still gets output in VS. Are there and build options to disable this check ?
No not at present, unless they're present in Boost.Build somewhere. Actually I *never* see this error message just the
Performing configuration checks - has_icu builds : no
part. I'm not sure what controls this, but I'll try and find out.
Please, it will help me prevent the build from stopping in VS.
This happens on the trunk version of boost, from svn, the release tarball indeed does not display the message. Actually this only happens when building boost as a custom build step in my project's build process, from Visual Studio 2008. Building from the command line does not display the message. Which might make sense, since the message does not follow output redirection anyway.
Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or sees some environment variables, and knows how to output the message ?
Yes, it's watching for VS_UNICODE_OUTPUT environment variable. http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Excelent !
I was still getting this problem with boost 1.44, so thank you for this information. Could boost better documented this somewhere ?
Better yet, could the regex build process start by unsetting this variable ? Should I report this somewhere ?
Do you always get those messages, or only when building a fresh tree for the first time?
The project pre-build event that I set up unpacks and compiles a boost release archive, that I place on source control as part of the project files, so I always compile a fresh tree. Sorry I can not answer your question. When a new boost version is released, I change the archive in the project source directory, and the Makefile deletes the previous version(s) and compiles the new one. Timothy Madden
Timothy Madden wrote:
On 02.09.2010 14:15, Vladimir Prus wrote:
Timothy Madden wrote:
On 8/16/2010 4:30 PM, Ilya Sokolov wrote:
Timothy Madden wrote:
John Maddock wrote:
> I get the following message when compiling boost from trunk: > > 1>Building the Boost C++ Libraries. > 1>has_icu_test.cpp > 1>libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot > open include file: 'unicode/uversion.h': No such file or directory > 1>Performing configuration checks > 1> - has_icu builds : no > > Although the build succeeds (as this is a test) Visual Studio > recognizes the error in the output and stops compiling the project > and reports the build as failed. > > Is there a way for me to suppress this message ? Or this test ? > > Attempting to redirect output with&>outfile.txt do not work as the > error messages still gets output in VS. Are there and build options > to disable this check ?
No not at present, unless they're present in Boost.Build somewhere. Actually I *never* see this error message just the
Performing configuration checks - has_icu builds : no
part. I'm not sure what controls this, but I'll try and find out.
Please, it will help me prevent the build from stopping in VS.
This happens on the trunk version of boost, from svn, the release tarball indeed does not display the message. Actually this only happens when building boost as a custom build step in my project's build process, from Visual Studio 2008. Building from the command line does not display the message. Which might make sense, since the message does not follow output redirection anyway.
Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or sees some environment variables, and knows how to output the message ?
Yes, it's watching for VS_UNICODE_OUTPUT environment variable. http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Excelent !
I was still getting this problem with boost 1.44, so thank you for this information. Could boost better documented this somewhere ?
Better yet, could the regex build process start by unsetting this variable ? Should I report this somewhere ?
Do you always get those messages, or only when building a fresh tree for the first time?
The project pre-build event that I set up unpacks and compiles a boost release archive, that I place on source control as part of the project files, so I always compile a fresh tree.
Ah, this explains. Can you arrange for <boost-root>/bin.v2 directory to be created before you try to build boost. 1.44 has a bug whereby config log is written to <boost-root>/bin.v2/config.log, but the directory is not created. - Volodya
[...]
Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or sees some environment variables, and knows how to output the message ?
Yes, it's watching for VS_UNICODE_OUTPUT environment variable. http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Excelent !
I was still getting this problem with boost 1.44, so thank you for this information. Could boost better documented this somewhere ?
Better yet, could the regex build process start by unsetting this variable ? Should I report this somewhere ?
Do you always get those messages, or only when building a fresh tree for the first time?
The project pre-build event that I set up unpacks and compiles a boost release archive, that I place on source control as part of the project files, so I always compile a fresh tree.
Ah, this explains. Can you arrange for<boost-root>/bin.v2 directory to be created before you try to build boost. 1.44 has a bug whereby config log is written to<boost-root>/bin.v2/config.log, but the directory is not created.
I tried to interrupt the build process and start it again. The bin.v2 directory was there, but still no use ...
Timothy Madden wrote:
[...]
> > Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or > sees some environment variables, and knows how to output the message ?
Yes, it's watching for VS_UNICODE_OUTPUT environment variable. http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Excelent !
I was still getting this problem with boost 1.44, so thank you for this information. Could boost better documented this somewhere ?
Better yet, could the regex build process start by unsetting this variable ? Should I report this somewhere ?
Do you always get those messages, or only when building a fresh tree for the first time?
The project pre-build event that I set up unpacks and compiles a boost release archive, that I place on source control as part of the project files, so I always compile a fresh tree.
Ah, this explains. Can you arrange for<boost-root>/bin.v2 directory to be created before you try to build boost. 1.44 has a bug whereby config log is written to<boost-root>/bin.v2/config.log, but the directory is not created.
I tried to interrupt the build process and start it again. The bin.v2 directory was there, but still no use ...
Ok -- and what if you set VS_UNICODE_OUTPUT environment variable before running the build? This would have to happen in your custom build step. - Volodya
On 04.09.2010 11:55, Vladimir Prus wrote:
Timothy Madden wrote:
[...]
>> >> Maybe cl.exe somehow feels it is invoked from a subprocess of VS, or >> sees some environment variables, and knows how to output the message ? > > Yes, it's watching for VS_UNICODE_OUTPUT environment variable. > http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Excelent !
I was still getting this problem with boost 1.44, so thank you for this information. Could boost better documented this somewhere ?
Better yet, could the regex build process start by unsetting this variable ? Should I report this somewhere ?
Do you always get those messages, or only when building a fresh tree for the first time?
The project pre-build event that I set up unpacks and compiles a boost release archive, that I place on source control as part of the project files, so I always compile a fresh tree.
Ah, this explains. Can you arrange for<boost-root>/bin.v2 directory to be created before you try to build boost. 1.44 has a bug whereby config log is written to<boost-root>/bin.v2/config.log, but the directory is not created.
I tried to interrupt the build process and start it again. The bin.v2 directory was there, but still no use ...
Ok -- and what if you set VS_UNICODE_OUTPUT environment variable before running the build? This would have to happen in your custom build step.
if I unset the variable, like set VS_UNICODE_OUTPUT=& .\bjam toolset=msvc-9.0 then nothings gets compiled. bjam just exists immediately and Visual Studio continues project compilation. I found that devenv.com, invoked from the command line with a simple solution file and with VS_UNICODE_OUTPUT unset, instead of cl.exe, can properly capture the output from cl, and can properly be redirected. Could the build process invoke devenv.com instead of cl.exe when testing for ICU for msvc-9.0 toolset ? And for msvc-10.0 I guess ... ? Thank you, Timothy Madden
On 9/4/2010 5:15 PM, Timothy Madden wrote:
On 04.09.2010 11:55, Vladimir Prus wrote:
Timothy Madden wrote:
[...]
>>> >>> Maybe cl.exe somehow feels it is invoked from a subprocess of >>> VS, or >>> sees some environment variables, and knows how to output the >>> message ? >> >> Yes, it's watching for VS_UNICODE_OUTPUT environment variable. >> http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD... >> > > Excelent ! > > I was still getting this problem with boost 1.44, so thank you > for this > information. Could boost better documented this somewhere ? > > Better yet, could the regex build process start by unsetting this > variable ? Should I report this somewhere ?
Do you always get those messages, or only when building a fresh tree for the first time?
The project pre-build event that I set up unpacks and compiles a boost release archive, that I place on source control as part of the project files, so I always compile a fresh tree.
Ah, this explains. Can you arrange for<boost-root>/bin.v2 directory to be created before you try to build boost. 1.44 has a bug whereby config log is written to<boost-root>/bin.v2/config.log, but the directory is not created.
I tried to interrupt the build process and start it again. The bin.v2 directory was there, but still no use ...
Ok -- and what if you set VS_UNICODE_OUTPUT environment variable before running the build? This would have to happen in your custom build step.
if I unset the variable, like set VS_UNICODE_OUTPUT=& .\bjam toolset=msvc-9.0 then nothings gets compiled. bjam just exists immediately and Visual Studio continues project compilation.
I found that devenv.com, invoked from the command line with a simple solution file and with VS_UNICODE_OUTPUT unset, instead of cl.exe, can properly capture the output from cl, and can properly be redirected.
Could the build process invoke devenv.com instead of cl.exe when testing for ICU for msvc-9.0 toolset ? And for msvc-10.0 I guess ... ?
Thank you, Timothy Madden
Phieewww ! I solved my problem: the damn nmake.exe must attempt some parsing on the commands it invokes, as it will run nothing following the & character on the command line. so set VS_UNICODE_OUTPUT=& .\bjam toolset=msvc-9.0 will not work in a makefile, but cmd /C "set VS_UNICODE_OUTPUT=& .\bjam toolset=msvc-9.0" will work as expected. The Microsoft nmake reference in MSDN does not mention & as a special character, though ... Timothy Madden
Yes, it's watching for VS_UNICODE_OUTPUT environment variable. http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Excelent !
I was still getting this problem with boost 1.44, so thank you for this information. Could boost better documented this somewhere ?
Better yet, could the regex build process start by unsetting this variable ? Should I report this somewhere ?
Do you always get those messages, or only when building a fresh tree for the first time?
The project pre-build event that I set up unpacks and compiles a boost release archive, that I place on source control as part of the project files, so I always compile a fresh tree.
Ah, this explains. Can you arrange for<boost-root>/bin.v2 directory to be created before you try to build boost. 1.44 has a bug whereby config log is written to<boost-root>/bin.v2/config.log, but the directory is not created.
I tried to interrupt the build process and start it again. The bin.v2 directory was there, but still no use ...
Just to complicate things further, I guess we really want to unset VS_UNICODE_OUTPUT only when doing the config, not the regular build - as in the latter case you might want to see the messages in the IDE? Could this be done with a new feature maybe? John.
On Sat, Sep 4, 2010 at 2:26 PM, John Maddock
> Yes, it's watching for VS_UNICODE_OUTPUT environment variable. > > http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD...
Excelent !
I was still getting this problem with boost 1.44, so thank you for this information. Could boost better documented this somewhere ?
Better yet, could the regex build process start by unsetting this variable ? Should I report this somewhere ?
Do you always get those messages, or only when building a fresh tree for the first time?
The project pre-build event that I set up unpacks and compiles a boost release archive, that I place on source control as part of the project files, so I always compile a fresh tree.
Ah, this explains. Can you arrange for<boost-root>/bin.v2 directory to be created before you try to build boost. 1.44 has a bug whereby config log is written to<boost-root>/bin.v2/config.log, but the directory is not created.
Maybe, I should try this. It might just solve my issue (listed below)
I tried to interrupt the build process and start it again. The bin.v2 directory was there, but still no use ...
Just to complicate things further, I guess we really want to unset VS_UNICODE_OUTPUT only when doing the config, not the regular build - as in the latter case you might want to see the messages in the IDE? Could this be done with a new feature maybe?
For me, this happens when I build for FreeBSD using a GCC cross compiler on GNU/Linux. I get a bunch of config messages in the build.log our build framework greps for 'error:' or 'warning:' and triggers the build as failure! To overcome this, I redirect all output into a file and prevent it from reaching pattern matching code. If I get a solution to prevent the config chatter from reaching the stdout, I can remove my hack. -dhruva
participants (5)
-
dhruva -
Ilya Sokolov -
John Maddock -
Timothy Madden -
Vladimir Prus