On 20.11.2013 12:26, jan i wrote:
On 20 November 2013 12:01, Andre Fischer <awf....@gmail.com> wrote:
On 20.11.2013 09:54, Herbert Duerr wrote:
On 20.11.2013 09:20, Andre Fischer wrote:
On 20.11.2013 08:33, Herbert Duerr wrote:
Please use the --without-stlport configure switch.
This option is the new default. Thanks to Jan for fixing configure.in.
But you'd need to update to the newest trunk version to benefit from
Jan's fix.
Is there any reason why we still need this option (be it default or
not)?
If there is a choice between step-wise evolution and a big-bang change
I'd always prefer the step-wise evolution.
I agree. But I would like steps that go from valid state to valid state.
From what I have heard I had the impression that the --without-stlport
option had only one valid value left and that using --with-stlport would
break the build.
Is there any scenario where we would need that switch to turn on
support for stlport?
A developer reusing the latest recipes from our snapshots page would fail
with the latest trunk if the --without-stlport option was no longer
recognized.
Would it not be better to update the recipes?
I would assume that removing the configure option and adapting the build
recipes take just a couple of hours to do. Would it not be better to spend
this additional time and make the change of removing support for stlport
complete in one step?
with my change to configure.in, you can choose to use --without-stlport or
not it has he same effect, meaning developers do not need to change
configure options.
Thanks for cleaning this up.
What is the timeline for removing this option completely?
-Andre
rgds
jan I.
-Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
