On 09/20/2012 08:48 AM, Tor Lillqvist wrote:
I think there is some fuzziness about what compiler options should be
part of the CC/CXX variables and what should be in
gb_CFLAGS/gb_CXXFLAGS.
In some cases, like my Mac build tree that uses the 10.4 SDK, from
Xcode 3 installed in /Xcode3, gb_CXXFLAGS contains at least one flag
that apparently *must* be used for also external projects (well,
liborcus in particular) to compile successfully. This is the
-isysroot from solenv/gbuild/platform/macosx.mk.
[...]
In other cases ("normal" Linuxes?) gb_CXXFLAGS contains just optional
flags that will in fact hurt an external project that isn't prepared
for them, like -Werror.
Should the -isysroot flag actually be part ot CC/CXX, not gb_CXXFLAGS?
Should configure.in and macosx.mk be modified thusly?
I think there has traditionally not been much consistency in this area
in OOo. Originally, I think this was exclusively handled via "flags
variables" (and re-crafting similar such variables for passing to
external projects, with values more or less similar to the primary OOo
variables). Much cruft here also stems from the fact that Sun's
internal OOo build environment required lots of overrides (as builds on
arbitrary machines used a centralized toolchain instead of a local one),
and this was typically achieved with ad-hoc fixes instead of a truly
principled approach.
That said, your rule of when to put something into CC/CXX vs.
gb_CXXFLAGS etc. sounds good to me.
Stephan
Context
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.