Re: [jamboost] Re: Bug in msvc.jam?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-10 04:30:00

Hello Konstantin,

> VP> I'm afraid I still don't understand the problem completely. If all
> VP> development boxes have *local* copies of user-config.jam, then only
>
> What does it mean *local*? We have root directory, say FOO, and all
> projects live there. FOO/BAR - BAR is a projects. FOO/boost-build -
> boost-buildis a Boost.Build folder. So I have to checkout BAR and
> boost-build to build this one. user-config.jam reside in buld/.... so we
> have one user-config.jam to use in all projects. Is it incorrect usage ?

"Local" means they are placed in user's home directory, for example, and not 
stored under version control. Your usage is not incorrect, it's just the 
usage that was not considered, yet.

> VP> compilers and libraries available on that box will be declared
> VP> there. Projects which rely on some other libraries won't built, but
> VP> all the other will built just OK.
>
> VP> Or the situation is that you include 'user-config.jam' (and
> VP> boost.build) in your projects tree? So, if 'user-config.jam' lists
> VP> all compilers, then somebody, after doing checkout runs "bjam" and
> VP> gets errors about msvc not found?
>
> Sounds like what we have :) See explanation above.

I understand now. So, my previous suggestion about placing "if" statements in 
user-config.jam won't work at all --- do find out that msvc is not available 
on this box, you'd need to do precisely the same as implemented in msvc.jam.
You've finally convinced me ;-) The solution is indeed simple: turn the error 
into warning. So, if you mispell msvc installation paths you'll get some 
diagnostic, but your use case will work as well.

If you agree with this, I can make the change rather quickly.

> VP> Oh, so this example is real ;-)
>
> Of course it is.
>
> project thirdparty ;
>
> lib postgres : : <file>Lib/win32/vc7/libpqdll.lib <toolset>msvc ;
> lib postgres : : <name>pq <toolset>gcc ;
>
> ^^^^^^^ and we have many thirdparty libs declared it this manner.

I see. In fact, it was always intended to work this way... but it's the first 
case where I know it's *really* used. (I have something similiar in my use 
case, but I don't count).

> VP> If you run bjam with "-d+10" option and send me the output, I'll be
> VP> able to say for sure. (Note that "-d+10" must be specified
> VP> immediately after "bjam").
>
> Done :)

Thanks. It appears that Jam code takes most of the time for your use case. 
We'll use this profile when optimizing.

- Volodya