On 25/10/10 17:19, Michael Meeks wrote:
On Mon, 2010-10-25 at 15:37 +0200, Rene Engelhard wrote:
My ideal is to have neither an enable or disable flag for any of the
optional pieces: KDE3 / KDE4 / GNOME etc. - but have a default of
auto-detection, so we only build if they are there.
I disagree. Even if you had auto-detection you still need those
options to *explicitely* en/dissable the features. There's reasons
you want to build without that stuff even when present.
Ah ! you mistake me; for the developers profile (the default build) we
should simply pass no configure option - and the default there should be
to auto-detect.
So. I'll try and improve my autoconf-fu :-)
First thing to check - I presume if no config is specified then the
variables get set to null, so I need to check for three states ie yes,
no and null.
If no, it gets left out.
If yes, it gets compiled in.
If null, it is autodetected and compiled if it's there.
Everything auto-detected is a sure way to break
Certainly - so packagers should explicitly pass --enable-foo or
--disable-foo depending on what they want, and if foo is not there it
should then break horribly :-)
So if it's yes but not there, then die like at present :-)
Surely that doesn't create problems for distros ? [ it is easy to add
the explicit flags to the distro configs ]
Yup.
HTH,
Michael.
I will accept the mission :-) I may be a long time ... (and I'll try and
document what I learn on the wiki build page :-)
Cheers,
Wol
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.