On Fri, Apr 3, 2009 at 12:15 AM, Vladimir Prus
<ghost@cs.msu.su> wrote:
On Friday 03 April 2009 04:43:26 Brian Davis wrote:
> I have the following Jamroot file below and I have been noticing a
> difference between MSVC command prompt and Cygwin (gcc).
Well, it's not MSVC command prompt, and gcc command prompt. Rather, it's
difference between running in Windows operating system, and the Cygwin
operating system. They happen to use different path naming conventions.
Yes this is a MSVC command prompt and a Cygwin command prompt. These are two separate environments. I have however run in cygwin shell: bjam toolset=msvc target-os=windows which is the second part of the question. The first part of the question is demonstrating some diffrence between:
1) MSVC command prompt
2) cygwin shell
when using path-constant and local variables.
It is in general unclear if passing paths in Windows syntax to random
Cygwin problem is going to work, or not.
Well it's pretty clear now that it's not working, though I wish it would :-(
I thought I got this to work in 1.34 or 1.36. I will have to try and test those versions of Jam. Come to think of it it may have been MinGW shell I guess I could try this too.
> I have two questions with this post:
>
> 1) What is the dealy-o with path-constant where locals are involved in the
> path and what is the difference (besides the obvious syntax difference
> between ms and cygwin path/directory syntax)?
>
> 2) Why does bjam swap between use of cygwin paths and dos paths in the build
> when in the cygwin environment building for toolset msvc
Can you clarify what problems does this cause?
Sure the post was a bit lengthy, but I tried to give you everything I was seeing. I even created a test project to try and resolve my issues. The first I ting was (see below) a problem, the second is just something that obviously it does not do, but something I would like to see bjam do. I also understand why it doesn't do it.
1) These examples were run in completely separate environments 1) MSVC command prompt and 2) Cygwin xterminal. The problem was found to be in the use of HOSTNAME.
Take the following snipit:
local HOSTNAME = [ modules.peek : HOSTNAME ] ;
path-constant INSTALL_ROOT_DIR : "$(HOSTNAME)/install" ;
#path-constant INSTALL_ROOT_DIR : "install/hostname" ;
Above works in Cygwin , but not in Win32 shells. I know this as I changed it to
#path-constant INSTALL_ROOT_DIR : "$(HOSTNAME)/install" ;
path-constant INSTALL_ROOT_DIR : "install/hostname" ;
And it worked in both shells... Question: Why did the first example fail in Win32?
THE ANSWER JUST DAWNED ON ME (DUH I should have remembered this)! HOSTNAME is not defined in Win32 so i have to use.
HOSTNAME = [ SHELL hostname ] ;
which is Win/Linux portable and trim that lovely ^M windows puts on the host name. The reason it breaks in windows is that HOSTNAME is not defined and and env variable.
I think I need to regex or MATCH this
local HOSTNAME = [ SHELL hostname ] ;
echo "=== $(HOSTNAME) ===" ;
local mat = [ MATCH "(.*)[\r\n]" : $(HOSTNAME) ] ;
echo "=== $(mat) === " ;
produces:
=== badboy
===
=== badboy ===
Sorry for wasting your time on above.
2) A desire to build msvc and gcc in one environment (second question). The problem here is obviously cygwin paths mixing with windows paths. It's 50% there as the actions use E:\whatever or C:\whateever, but the modules are using /cygdrive/e/... and /cygdrive/f. What would be desired here is that when msvc is specified that the jam modules would use E:\whatever or C:\whatever not /cydrive/e etc.
Now the second question is obviously a desirement, but I have configured Eclipse Project(right-click)->C/C++ Build and added a configuration for Win32 specifying .../jam/src/bjam.ntx86 for the PATH and set a Cygwin build configuration specifying .../jam/src/bjam.cygwinx86 in the PATH for that configuration and this allows me to somewhat quickly build and test msvc and gcc. However bjam toolset=msvc,gcc -d+2 would be quicker in cygwin.
Brian
- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build