Re: Reworking the MSVC-related build options

Le Wed, 05 Dec 2012 16:56:23 +0100, Norbert Thiebaud <nthiebaud@gmail.com>  
a écrit:

> On Wed, Dec 5, 2012 at 9:43 AM, Tor Lillqvist <tml@iki.fi> wrote:
> > > to be able to reproduce a scenario: build using the same config than
> > > the one that broke ?
> >
> > Hmm, but there are tons of stuff that can break in various ways,
> > should we have options permanently in there to intentionally reproduce
> > all of them?
>
> if something _is_ optional then both way should 'work' (that is not
> abend/cpu-loop/eat-you-document if one try to use a feature that
> require that 'option' for instance'
> And therefore it is usefull to be able to force that options on build.

As stated by [1], "Remove DirectX implementation for the new XCanvas  
interface."
As came from blame, option was added in 2004 [3]:
 "2004/05/08 04:44:48 waratah 1.63.8.6: #i26548# Change directx default to  
on and allow disable"

Since 2004, we can assume we only need to disable in special cases (since  
it is the default, and fallback may deprecate anytime from now). I am in  
favor of removing --disable-directx and --with-directx-home, warning that  
we did not found DXSDK_DIR and it needs to be set if desired.
DXSDK_DIR seems to be provided by installer, so we can complain about not  
finding it.
and Directx SDK is part of prerequisites [2].If you ever need to disable  
it, just unset DXSDK_DIR.


> I'm agreeing completely with you that in the absence of any user
> input, autogen should pick up the mos recent VS available and DirectX
> if available etc..
> I also strongly agree that a single argument to select the VS version
> when one has more than one is desirable to select a
> consistent/coherent set of values
> but still the ability to override is still desirable in corner case...
> that may not have to be via argument from the command line.. that can
> also
> be like for CC, if the value is set in the env, then honor it,
> otherwise find a best effort value.
>
> Norbert
>
> PS: if there are combination of options that are not supported,
> autogen _should_ ideally block them. for instance if system-python is
> incompatible with internal-openssl, then that should be detected and
> blocked at configure time.
we agree


[1]  
http://wiki.documentfoundation.org/Development/How_to_build/Configure_options
[2]  
http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies
[3]  
http://cgit.freedesktop.org/libreoffice/core/commit/?id=1c01781236a2ea76217f6cad300dfbdfe5ce5ba4

--
Mat M