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

On Wed, Dec 5, 2012 at 9:43 AM, Tor Lillqvist <t...@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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to