Hi Norbert, *,
On Sat, Jul 23, 2011 at 5:57 AM, Norbert Thiebaud <nthiebaud@gmail.com> wrote:
Like for example?
Mac OSX was the first platform to be WaE free, despite some
over-pickyness of the compiler. What pain did gcc 4.0 bring?
actually I'm compiling with SDK 10.5 and gcc 4.2.1 right now and it is
picking up quite few more WaE.
so gcc-4.0 is not over-picky, quite the contrary...
Well, it is picki in areas where there actually is no problem, like
not detecting when a variable is initialized by overloaded operators
and similar stuff.
and that is
probably why we get away with -Werror on Mac.
No, we get away with it because "we" (at OOo times already) just did
use -Werror from the very beginning it was introduced. And having a
single system, a single compiler for Mac as opposed to having various
different patched versions, different versions by itself on LInux made
fixing the problems an rather easy task.
Also 10.4 + gcc 4.0 means 32 bits only... I'm finding issue with 64
bits support and deprecated stuff in Cairo for instance( like
something similar to
64bits for an office suite is questionable anyway.
And exactly those deprecation stuff will very likely break
compatibility with 10.4 when the person who builds against a newer SDK
doesn't bother to check whether the replacement is available in 10.4
already.
That's why I'm against making it easy to break without noticing.
On Fri, Jul 22, 2011 at 7:08 PM, Christian Lohmaier
<lohmaier+libreoffice@googlemail.com> wrote:
On Fri, Jul 22, 2011 at 7:18 PM, Norbert Thiebaud <nthiebaud@gmail.com> wrote:
That is just twisting the truth. Sure, 10.4 support is not "dropped",
but the effect is the same. So I'm still not pleased with it.
Ok so what if I made the default to 10.4 in configure.in so that one
can only build against another SDK if he explicitly ask for it ?
That would be OK with me.
I'm not against building with a newer SDK to check out where things
are lacking and to make the SDK configurable. But the start of this
thread was right about dropping 10.4 support. (and not "forcing" to
use 10.4 SDK on builders is like dropping 10.4 support throught the
back-door) And that is nothing I support.
Tor's message contains the only valid reason for dropping 10.4
support: You absolutely need to use a newer compiler.
Any other reason than that is invalid. Then whether the baseline is
10.4 or 10.5 - when using new features of Lion, you have to provide
two codepaths / a fallback nevertheless.
The problem right now is that you CANNOT use any other SDK since 10.4
is hard-coded
so 'new feature' are out of question, two codpath/fallback or not.
But that's a completely different topic than raising the baseline.
As long as the solution to "your change broke the build on 10.4" is
"just revert the change" I'm fine with it. The person who did break
the build did so on purpose by ignoring configure/overriding the SDK.
It is his/her fault for wasting time/not providing
backwards-compatibility.
If however the answer is "look, 10.4 is soooo old, get over with and
let it die", I'm against it.
ciao
Christian
PS: In theory, you don't have to compile against the 10.4 SDK to
ensure compatibility with 10.4, but in practice relying on
api-versioning just doesn't work reliably, at least causes problems
when linking (or worse you don't detect them when linking, but when
trying to actually run it on the baseline system.
Context
- Re: [Libreoffice] Mac OS 10.4 Support (continued)
Re: [Libreoffice] Mac OS 10.4 Support · Christian Lohmaier
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.