Hi all, I finally installed vc8 beta. It seems that vc8-tools.jam has the path to the binary MSVC tools wrong: It is: VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio .NET Whidbey\\VC7" ; But I think it should be: VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio 8\\VC" ; At least that's what's needed on my machine... As a side note, I got a lot of warnings: cl : Command line warning D9035 : option 'GX' has been deprecated and will be re moved in a future release cl : Command line warning D9036 : use 'EHsc' instead of 'GX' Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
"John Torjo" <john.lists@torjo.com> wrote in message news:415C4CF4.8070509@torjo.com...
Hi all,
I finally installed vc8 beta.
It seems that vc8-tools.jam has the path to the binary MSVC tools wrong:
It is:
VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio .NET Whidbey\\VC7" ;
But I think it should be:
VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio 8\\VC" ;
At least that's what's needed on my machine...
Same on my system. Jonathan
John Torjo wrote:
Hi all,
I finally installed vc8 beta.
It seems that vc8-tools.jam has the path to the binary MSVC tools wrong:
It is:
VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio .NET Whidbey\\VC7" ;
But I think it should be:
VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio 8\\VC" ;
At least that's what's needed on my machine...
Yes. Same with mine. I posted this information for BBv2, so v2 gets it right :).
As a side note, I got a lot of warnings:
cl : Command line warning D9035 : option 'GX' has been deprecated and will be removed in a future release cl : Command line warning D9036 : use 'EHsc' instead of 'GX'
There are also a few other deprecated switches (like GS, I think). These have also been taken into account on BBv2, they just haven't filtered over to v1. Also, as an aside, when I build a program with BBv2 using VC8, I get warnings of the form: d:\devel\libraries\boost\1.31.0\libs\test\src\execution_monitor.cpp(572) : warning C4996: 'strncat' was declared deprecated C:\Program Files\Microsoft Visual Studio 8\VC\include\string.h(114) : see declaration of 'strncat' The deprecated symbol warning should preferably be disabled via Boost.Build for this release (1.32) with the aim of possibly resolving them at some point during the preparation for the next (1.33) release. Regards, Reece
"Reece Dunn" <msclrhd@hotmail.com> wrote
d:\devel\libraries\boost\1.31.0\libs\test\src\execution_monitor.cpp(572) : warning C4996: 'strncat' was declared deprecated C:\Program Files\Microsoft Visual Studio 8\VC\include\string.h(114) : see declaration of 'strncat'
Nice to see you people are catching up after almost a month that I posted the same findings both here and on jam build egroup that all went to neverneverland :( As for the strings, MS wants you to use *secure* variants with "_s" (underscore s) appended to the function name. Cheers, Tony
At Thursday 2004-09-30 11:14, you wrote:
Hi all,
I finally installed vc8 beta.
It seems that vc8-tools.jam has the path to the binary MSVC tools wrong:
it's vc8.0-tools.jam and I thought we'd addressed those problems by referencing off the environment variable VS80COMNTOOLS which is on both of my systems on which Visual Studio 2005 beta is installed.
It is:
VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio .NET Whidbey\\VC7" ;
But I think it should be:
VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio 8\\VC" ;
At least that's what's needed on my machine...
As a side note, I got a lot of warnings:
cl : Command line warning D9035 : option 'GX' has been deprecated and will be re moved in a future release cl : Command line warning D9036 : use 'EHsc' instead of 'GX'
Best, John
-- John Torjo -- john@torjo.com
Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
it's vc8.0-tools.jam of course ;)
and I thought we'd addressed those problems by referencing off the environment variable VS80COMNTOOLS which is on both of my systems on which Visual Studio 2005 beta is installed.
That should work too. Something like: VS80COMNTOOLS/../../VC8 Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
At Friday 2004-10-01 04:00, you wrote:
it's vc8.0-tools.jam of course ;)
and I thought we'd addressed those problems by referencing off the environment variable VS80COMNTOOLS which is on both of my systems on which Visual Studio 2005 beta is installed.
That should work too. Something like:
VS80COMNTOOLS/../../VC8
This is what's currently in the CVS extends-toolset msvc ; # singleton variables... set-as-singleton VC80_ROOT ; if ! $(MSVCDir) { if $(VS80COMNTOOLS) { VC80_ROOT ?= $(VS80COMNTOOLS:J=" ")..\\..\\VC ; VC_TOOL_PATH = "$(VC80_ROOT)"\\bin\\ ; VC_SETUP = "CALL \"$(VC_TOOL_PATH)VCVARS32.BAT\" >nul" ; } else { ProgramFiles ?= $(PROGRAMFILES) ; VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio 8\\VC" ; VC_TOOL_PATH = "$(VC80_ROOT)"\\bin\\ ; VC_SETUP = "CALL \"$(VC_TOOL_PATH)VCVARS32.BAT\" >nul" ; } } VC_PDB_NAME = vc80 ; feature native-wchar_t : on off ; flags vc8.0 C++FLAGS : /Zc:forScope ; flags vc8.0 C++FLAGS <native-wchar_t>on : /Zc:wchar_t ; # The following #// line will be used by the regression test table generation # program as the column heading for HTML tables. Must not include version number. #//<a href="http://msdn.microsoft.com/vstudio/whidbey/default.aspx">Micro-<br>soft<br>VC++</a>
Best, John
-- John Torjo -- john@torjo.com
Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Hmmm, I hadn't realized John was going to change it (we went to all the trouble of checking for the environment variable just so we COULD keep the original path) John, I think looking in the registry is a BAD idea... the Environment variables are readily visible to users, the registry is NOT At Friday 2004-10-01 07:15, you wrote:
At Friday 2004-10-01 04:00, you wrote:
it's vc8.0-tools.jam of course ;)
and I thought we'd addressed those problems by referencing off the environment variable VS80COMNTOOLS which is on both of my systems on which Visual Studio 2005 beta is installed.
That should work too. Something like:
VS80COMNTOOLS/../../VC8
This is what's currently in the CVS
extends-toolset msvc ;
# singleton variables... set-as-singleton VC80_ROOT ;
if ! $(MSVCDir) { if $(VS80COMNTOOLS) { VC80_ROOT ?= $(VS80COMNTOOLS:J=" ")..\\..\\VC ; VC_TOOL_PATH = "$(VC80_ROOT)"\\bin\\ ; VC_SETUP = "CALL \"$(VC_TOOL_PATH)VCVARS32.BAT\" >nul" ; } else { ProgramFiles ?= $(PROGRAMFILES) ; VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio 8\\VC" ; VC_TOOL_PATH = "$(VC80_ROOT)"\\bin\\ ; VC_SETUP = "CALL \"$(VC_TOOL_PATH)VCVARS32.BAT\" >nul" ; } }
VC_PDB_NAME = vc80 ;
feature native-wchar_t : on off ;
flags vc8.0 C++FLAGS : /Zc:forScope ; flags vc8.0 C++FLAGS <native-wchar_t>on : /Zc:wchar_t ;
# The following #// line will be used by the regression test table generation # program as the column heading for HTML tables. Must not include version number. #//<a href="http://msdn.microsoft.com/vstudio/whidbey/default.aspx">Micro-<br>soft<br>VC++</a>
Best, John
-- John Torjo -- john@torjo.com
Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law" _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." wrote:
John, I think looking in the registry is a BAD idea... the Environment variables are readily visible to users, the registry is NOT
Heh.. some contrarian approach. In general Windoze Registry s**** big time. However, environment variables are really for people from a few centuries ago, the folks that works on a single program until they get retired with honors and magazine articles written in their honir :) Work on more than 3 open-source cross-platform programs at one time and then you'll realize how lame is this whole environment variables idea. You want me to pump up my environment as each and every program that I work with keeps adding its requirements on the environment? I don't think even Dennis Ritchie would support it nowadays. Tony
I've heard rumors that even MS had finally recognized that the registry was a bad idea. So, whatcha gonna do when it disappears? At Friday 2004-10-01 12:16, you wrote:
"Victor A. Wagner Jr." wrote:
John, I think looking in the registry is a BAD idea... the Environment variables are readily visible to users, the registry is NOT
Heh.. some contrarian approach. In general Windoze Registry s**** big time. However, environment variables are really for people from a few centuries ago, the folks that works on a single program until they get retired with honors and magazine articles written in their honir :)
Work on more than 3 open-source cross-platform programs at one time and then you'll realize how lame is this whole environment variables idea. You want me to pump up my environment as each and every program that I work with keeps adding its requirements on the environment? I don't think even Dennis Ritchie would support it nowadays.
Tony
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." wrote:
I've heard rumors that even MS had finally recognized that the registry was a bad idea. So, whatcha gonna do when it disappears?
I doubt that they will get rid of it entirely, for application compatibility reasons. But, in theory, in such case I would use *.ini files, eventually in XML format. Environment easily gets too large, too messy and unmanageable (especially when you add also Java and/or Python) and I can not understand why would each tool or app pollute global environment. If you think a bit about it, there is no huge difference between the environment and the registry except that latter has a tree structure (as opposed to flat key-value environment) and does not get passed to each app as a block of memory. Tony
Tony Juricic wrote: <snip>
Environment easily gets too large, too messy and unmanageable (especially when you add also Java and/or Python) and I can not understand why would each tool or app pollute global environment. If you think a bit about it, there is no huge difference between the environment and the registry except that latter has a tree structure (as opposed to flat key-value environment) and does not get passed to each app as a block of memory.
Under Windows it is common to set environment variables on a per-computer or per-user basis - in which case they are stored in the registry, loaded by Windows Explorer and passed on to the processes it spawns. If you're used to this way of doing things I can see why you might not appreciate the use of environment variables. However, there is a huge difference: registry settings (and configuration files) have static scope whereas environment variables have dynamic scope, and dynamic scope is sometimes very useful. You can easily change environment variables on a per-session or per-command basis. However, I agree that they should be used sparingly. Ben.
Hmmm, I hadn't realized John was going to change it (we went to all the trouble of checking for the environment variable just so we COULD keep the original path)
John, I think looking in the registry is a BAD idea... the Environment variables are readily visible to users, the registry is NOT
Just to be clear here - I haven't changed anything yet - or even experimented with such a change, more like thinking out loud. However if a particular toolset readily identifies itself in the registry, that seems to be a lot more reliable than messing with environment variables that the user has to type in every time they want to use Boost. BTW the Metrowerks jam-toolset already works this apparently. John.
John Maddock wrote:
Hmmm, I hadn't realized John was going to change it (we went to all the trouble of checking for the environment variable just so we COULD keep the original path)
John, I think looking in the registry is a BAD idea... the Environment variables are readily visible to users, the registry is NOT
However if a particular toolset readily identifies itself in the registry, that seems to be a lot more reliable than messing with environment variables that the user has to type in every time they want to use Boost.
And less documentation that they have to read and apply. If it "just works" without setting any ENV variables the more likely people are to use it.
BTW the Metrowerks jam-toolset already works this apparently.
Yes it does. And it's working out very well, and without complaints. Something people should remember is that using the registry doesn't preclude using the ENV vars. The CW toolset still allows overriding the toolset location the "old fashioned" way. --grafik
At Saturday 2004-10-02 06:40, you wrote:
John Maddock wrote:
Hmmm, I hadn't realized John was going to change it (we went to all the trouble of checking for the environment variable just so we COULD keep the original path)
John, I think looking in the registry is a BAD idea... the Environment variables are readily visible to users, the registry is NOT However if a particular toolset readily identifies itself in the registry, that seems to be a lot more reliable than messing with environment variables that the user has to type in every time they want to use Boost.
And less documentation that they have to read and apply. If it "just works" without setting any ENV variables the more likely people are to use it.
damnit!!!! read what I type, not what you THINK I typed I said it was easier for the user to SEE AND there should have been nothing wrong with the vc8.0-tools.jam that was already IN the repository. Unfortunately, I'm off for 4 days to visit w/ daughter in from Scotland and you guys will go off and do what you want, and I won't be here to rebut....have fun NOBODY HAS EXPLAINED WHY THERE WAS A PROBLEM IN THE 1ST PLACE!!!!!!!!
BTW the Metrowerks jam-toolset already works this apparently.
Yes it does. And it's working out very well, and without complaints. Something people should remember is that using the registry doesn't preclude using the ENV vars. The CW toolset still allows overriding the toolset location the "old fashioned" way.
and I NEVER suggested overriding any how. It is my FIRM opinion that the person who originally complained about this hadn't updated his/her toolset (and they've been strangely silent ever since _I_ posted what was IN the repository at the time they complained. Yes I'm angry hope to return very late Tuesday (MST (AZ time)
--grafik _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
And less documentation that they have to read and apply. If it "just works" without setting any ENV variables the more likely people are to use it.
damnit!!!! read what I type, not what you THINK I typed I said it was easier for the user to SEE
Chill out, Victor. A little patience goes a long way. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
and I NEVER suggested overriding any how. It is my FIRM opinion that the person who originally complained about this hadn't updated his/her toolset (and they've been strangely silent ever since _I_ posted what was IN the repository at the time they complained.
Are you talking about me? I assume that you made the right changes. And yes, I did not update my toolset for a couple of reasons. The main reason is that I have about 5 projects that use the rangelib (http://www.torjo.com/rangelib/), which uses some boost headers that are not available anymore. At this time I'm extremely busy, and hopefully early next week I'll get to update rangelib to the latest boost - and finally get the latest toolset. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
At Saturday 2004-10-02 03:11, you wrote:
Hmmm, I hadn't realized John was going to change it (we went to all the trouble of checking for the environment variable just so we COULD keep the original path)
John, I think looking in the registry is a BAD idea... the Environment variables are readily visible to users, the registry is NOT
Just to be clear here - I haven't changed anything yet - or even experimented with such a change, more like thinking out loud.
It was to THIS change I referred when I said: "John was going to change" no change should have been necessary......................... T:\Projects\boost\tools\build\v1>cvs log vc8.0-tools.jam RCS file: /cvsroot/boost/boost/tools/build/v1/vc8.0-tools.jam,v Working file: vc8.0-tools.jam head: 1.4 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 4; selected revisions: 4 description: ---------------------------- revision 1.4 date: 2004/10/01 10:39:16; author: johnmaddock; state: Exp; lines: +2 -1 Updated default install path to reflect current Beta. ----------------------------
However if a particular toolset readily identifies itself in the registry, that seems to be a lot more reliable than messing with environment variables that the user has to type in every time they want to use Boost.
I didn't suggest that the user type in anything, I suggested we use the environment variable(s) which are put there by the install process.
BTW the Metrowerks jam-toolset already works this apparently.
John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Just to be clear here - I haven't changed anything yet - or even experimented with such a change, more like thinking out loud.
It was to THIS change I referred when I said: "John was going to change" no change should have been necessary.........................
OK, I misunderstood, apologies. Note however that if their install defines VS80COMNTOOLS system wide then the change I made *will have no effect*. However is it possible to install VC++ for a single user rather than system wide? I don't know - but you can with most tools - but it's been a while since I've installed VC++ and can't remember: but if you can then I wouldn't expect VS80COMNTOOLS to be set system wide.
However if a particular toolset readily identifies itself in the registry, that seems to be a lot more reliable than messing with environment variables that the user has to type in every time they want to use Boost.
I didn't suggest that the user type in anything, I suggested we use the environment variable(s) which are put there by the install process.
You're right, on reflection the toolset as it stands now will work without the user having to set anything: you're obviously way ahead of me, so I'll just shut up now ;-) John.
It seems that vc8-tools.jam has the path to the binary MSVC tools wrong:
It is:
VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio .NET Whidbey\\VC7" ;
But I think it should be:
VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio 8\\VC" ;
OK, thanks, toolset updated - in the long run though we should really be using the registry for this. John.
"John Maddock" wrote:
OK, thanks, toolset updated - in the long run though we should really be using the registry for this.
I very much agree. The first time that I read this: # Some installations set MSVCDIR instead of MSVCDir; who knows why? MSVCDir ?= $(MSVCDIR) ; # If MSVCDir is not set the user hasn't run VCVARS32.BAT if ! $(MSVCDir) I couldn't help thinking: why do these people bother with this? Tony
participants (9)
-
Ben Hutchings -
David Abrahams -
John Maddock -
John Torjo -
Jonathan Turkanis -
Reece Dunn -
Rene Rivera -
Tony Juricic -
Victor A. Wagner Jr.