Boost logo

Boost :

Subject: Re: [boost] Default variants on windows
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2009-04-11 06:14:11


Vladimir Prus wrote:
> Thanks everybody for the feedback. I think that conclusions are:
>
> 1. Autolink defaults to static linking, and it's best if
> default build of Boost match autolink default, so I'll change
> Jamroot to build static libraries by default on windows.

I understood it differently: Autolink doesn't default to anything, but simply does what is specified by the linker options. If my understanding is correct, the statement "Autolink defaults to..." is at least misleading.

> 2. IDE default is:
>
> runtime-link=dynamic, threading=multi, variant=(debug|release)
>
> and it's good to match IDE too. Therefore, on windows we'll build
>
> link=static runtime-link=dynamic threading=multi variant=debug

When the IDE defaults to both debug and release, how can you conclude "THEREFORE we'll build only debug"?

That said, I think it's a good idea to not build the release variant by default, because of the SCL_SECURE issue.

> Anybody thinks we should also build
>
> link=static runtime-link=dynamic threading=multi variant=release
>
> ? It seems reasonable if IDE creates release variant as well.

I just verified that the IDE creates release by default as well. However, the default compiler and linker options of the release variant are not suitable for really releasing something built with these options. And because SCL_SECURE even leads to ABI incompatibility, it's probably better not to built release by default, but explaining the issues and how to resolve them instead.
I had a look at http://www.boost.org/doc/libs/1_38_0/more/getting_started/windows.html#invoke-bjam to see how this is currently explained, and it really just says "For instructions on how to build only specific variants, please ask on the Boost.Build mailing list." This is both good and bad. It's good to teach developers that they are allowed to ask questions, but it's bad to teach them to be "careless" about the "accessibility" of documentation.

Regards,
Thomas


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk