distro-configs files, autogen.sh options, defaults etc

I am once again pretty confused.

From a high-level point of view, what is the intent:

- Should a new, naïve contributor be able to run just ./autogen.sh
without any options and, assuming his platform is a reasonably well
supported one, get a working, perhaps minimal (i.e. quicker/easier to
build) build? (I think YES.)

- Or are you always expected to pass a --with-distro=YourOS switch? (I
think NO.)

- Surely only official TDF builds are supposed to use
--with-vendor=The Document Foundation ? (Sure, we can't *prevent*
random people from passing whatever they want as --with-vendor, but I
mean we don't want random buillds that somebody might give to a few
friends, or offer to a wider public, to claim to be from TDF, right?)
(I think INDEED.)

Currentlly how configure.in and the distro-configs files work is a bit
confusing, and doesn't really give an impression of any clear overall
policy regarding the above points.

If I understand correctly, the distro-configs files should not contain
any such --enable / --disable switches that are *required* for the
build to succeed on the platform in question. Right? So for instance
the --disable-cairo-canvas should not be in LibreOfficeMacOSX.conf and
LibreOfficeWin32.conf, but instead the enable_cairo_canvas should be
hardcoded as "no" always for MacOSX and Windows?

--tml
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tue, 2012-04-24 at 10:24 +0300, Tor Lillqvist wrote:
> I am once again pretty confused.
>
> From a high-level point of view, what is the intent:
>
> - Should a new, naïve contributor be able to run just ./autogen.sh
> without any options and, assuming his platform is a reasonably well
> supported one, get a working, perhaps minimal (i.e. quicker/easier to
> build) build? (I think YES.)

Yes, ./autogen.sh should "just work" and it should also give the correct
default best configuration, rather than a "minimal" one IMO. The two of
those are a little contradictory, so when they conflict default to "just
work".

> - Or are you always expected to pass a --with-distro=YourOS switch? (I
> think NO.)

I think no as well.

> - Surely only official TDF builds are supposed to use
> --with-vendor=The Document Foundation ?

Yeah, and its even fair to suggest that people use --with-distro or
whatever that injects "The Document Foundation" as the vendor into their
config options because you need the right permissions to do that.
http://wiki.documentfoundation.org/TradeMark_Policy#Overall_Guidelines
'The logos that bear the exact mention of the software name with the
mention "The Document Foundation" are reserved for two purposes:

    the sole and official use of TDF as an entity, for instance on
splash screens from software builds compiled by the Document Foundation
or on official materials from the legal entity itself ...'

> Currentlly how configure.in and the distro-configs files work is a bit
> confusing, and doesn't really give an impression of any clear overall
> policy regarding the above points.

Well, the distro-configs are really a bag on the side aren't they ? Now
really convenience configurations for the universal builds.

> the enable_cairo_canvas should be hardcoded as "no" always for MacOSX
> and Windows?

I imagine so, the ./autogen.sh ... route should "just work".

C.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tue, Apr 24, 2012 at 10:24:33AM +0300, Tor Lillqvist wrote:
> From a high-level point of view, what is the intent:

Provocative reply: Keep backwards compatibility with libreoffice-build/go-oo
concepts. They were migrated over from there.

> - Should a new, naïve contributor be able to run just ./autogen.sh
> without any options and, assuming his platform is a reasonably well
> supported one, get a working, perhaps minimal (i.e. quicker/easier to
> build) build? (I think YES.)

Yes.

> - Or are you always expected to pass a --with-distro=YourOS switch? (I
> think NO.)

Indeed, thats how it should be.

> - Surely only official TDF builds are supposed to use
> --with-vendor=The Document Foundation ? (Sure, we can't *prevent*
> random people from passing whatever they want as --with-vendor, but I
> mean we don't want random buillds that somebody might give to a few
> friends, or offer to a wider public, to claim to be from TDF, right?)
> (I think INDEED.)

Right.

> Currentlly how configure.in and the distro-configs files work is a bit
> confusing, and doesn't really give an impression of any clear overall
> policy regarding the above points.

Agreed. I think, to name this ./autogen.sh switch and the configs for what they
do could help a lot here. That means:

 rename --with-distro to --with-preset
 rename LibreOfficeAndroid.conf to TDFReleaseAndroid.conf etc.

possibly we could also add something like:

 UbuntuDev.conf
 FedoraDev.conf
 ...

containing sane --with-system-switches and --disable-mozilla/disable-binfilter
etc.

> If I understand correctly, the distro-configs files should not contain
> any such --enable / --disable switches that are *required* for the
> build to succeed on the platform in question. Right? So for instance
> the --disable-cairo-canvas should not be in LibreOfficeMacOSX.conf and
> LibreOfficeWin32.conf, but instead the enable_cairo_canvas should be
> hardcoded as "no" always for MacOSX and Windows?

In theory yes, in practice you will risk an endless bikeshedding fight over
some enable/disable switch defaults. Having these .conf files might help a bit
there.

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

2012/4/24 Bjoern Michaelsen <[hidden email]>:
>
> In theory yes, in practice you will risk an endless bikeshedding fight over
> some enable/disable switch defaults. Having these .conf files might help a bit
> there.
>
To avoid bikeshed here we could do automagic approach.

All switches are by default on enable state and we check for the deps.
If the damn deps are not present on the system we switch the feature
off.
If user explicitely wants something he can pass --enable-something to
have configure fail if the dep is not around.

Tom
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tue, 2012-04-24 at 10:18 +0200, Bjoern Michaelsen wrote:
> possibly we could also add something like:
>
>  FedoraDev.conf
>  ...

Personally I wouldn't bother. ./autogen.sh should give a generic
configuration out of the box while something like a "FedoraDev" would
map to "the set of configure options used by the fedora LibreOffice
maintainers for rawhide" and rawhide's a rolling target so it'll often
be out of date, you just end up with a gadzillion stale distro
configurations which try and shadow the "real" configuration tucked away
inside each distro's rpm .spec or equivalent.

C.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tue, 2012-04-24 at 10:31 +0200, Tomáš Chvátal wrote:
> All switches are by default on enable state and we check for the deps.
> If the damn deps are not present on the system we switch the feature
> off.

Some packages do this, and it leads to the nightmare situation that you
silently get a different result depending on what packages you happen to
install. So you have loads of stuff installed locally and you get one
result. You build it through mock with only exactly the packages
required to fulfill every component in the dependency tree and you get a
different result. If something you depend on itself pulls in a new
dependency in a point release of itself, which happens to be something
LibreOffice could use, but didn't before, then you get a completely new
configuration because say gtk decided to depend on graphite and you flip
functionality between builds, *shudder*.

Nah, just pick a default configuration and everyone gets the same one
(within reason) when they do "./autogen.sh"

C.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tuesday 24 of April 2012, Caolán McNamara wrote:
> On Tue, 2012-04-24 at 10:31 +0200, Tomáš Chvátal wrote:
> > All switches are by default on enable state and we check for the deps.
> > If the damn deps are not present on the system we switch the feature
> > off.
>
> Some packages do this,

 Isn't that more like "most packages", actually?

 Yes, but who cares? Nobody except for possibly some of those 10 packages, who
can be explicit about the options if they really want. Right now all those
100 developers have to have a long list of options, half of them because they
are needed, other half because they'd prefer not to build repeatedly stuff
they already have installed. I still remember doing my very first build when
I asked how do I do the build and was handed thiiis long list of options
*shudder*.

> Nah, just pick a default configuration and everyone gets the same one
> (within reason) when they do "./autogen.sh"

 Besides, this is discussing a problem which has a reasonably simple technical
solution. It would be enough if --enable-system-libs=auto existed and was the
default. Bonus points if configure at the end printed a list of which
external dependencies were and were not picked up.

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

I wonder, by the way, if we really need to have all the
configurability we currently have... To keep bringing up the cairo
canvas as an example: if it works, why wouldn't it be enabled all the
time on Unix?

--tml
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tue, 2012-04-24 at 11:49 +0200, Lubos Lunak wrote:
> On Tuesday 24 of April 2012, Caolán McNamara wrote:
> > On Tue, 2012-04-24 at 10:31 +0200, Tomáš Chvátal wrote:
> > > All switches are by default on enable state and we check for the deps.
> > > If the damn deps are not present on the system we switch the feature
> > > off.
> >
> > Some packages do this,
>
>  Isn't that more like "most packages", actually?

*shrug*, I don't have a sample size, its still a pain in the ass. Even
Gentoo has a page bitching about autoconf automagic dependencies
somewhere.

> Right now all those 100 developers have to have a long list of options,
> half of them because they are needed, other half because they'd prefer
> not to build repeatedly stuff they already have installed

I don't really get why developers are using vast long lists of options.
./autogen.sh
+ a few dev-mode options like werror, dbgutil or debug seems to make
sense
./autogen.sh --with-system-libs if people want to skip building stuff
they have installed already

Surely all the other micro-level with-system-this-that-or-the-other
should be left to the distro maintainers to work around what they've got
or not in any given release.

If there's other stuff being turned on all the time, surely we can just
default those on.

C.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tue, Apr 24, 2012 at 09:57:37AM +0100, Caolán McNamara wrote:
> Some packages do this, and it leads to the nightmare situation that you
> silently get a different result depending on what packages you happen to
> install.

Agree, that indeed is a nightmare. What could still work is:

 ./autogen.sh --automagic

which is still short enough without loosing strictlness in the default (and
also gives people a hint why their configure "suddenly broke, although I didnt
change anything").

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Tor Lillqvist wrote:
> I wonder, by the way, if we really need to have all the
> configurability we currently have...
>
As generic as the question is: probably not.

> To keep bringing up the cairo canvas as an example: if it works,
> why wouldn't it be enabled all the time on Unix?
>
Why not? The work to have it configurable is all done, and it's
truly runtime-optional. I would think effort to reduce complexity
is, for the while, better invested elsewhere. ;)

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tue, Apr 24, 2012 at 03:45:38PM +0200, Thorsten Behrens wrote:
> Tor Lillqvist wrote:
> > I wonder, by the way, if we really need to have all the
> > configurability we currently have...
> >
> As generic as the question is: probably not.

As someone who does releases on a fixed schedule, I find quite a few of the
options comforting. If there is a last minute showstopper these options can be
very helpful (e.g. switching --without-system-foo to avoid a specific problem).
That doesnt mean I defend all of the switches, but in general, most give me a
fuzzy warm feeling.

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tuesday 24 of April 2012, Caolán McNamara wrote:
 But that doesn't work, that's the point.

 Running "./autogen.sh --with-system-libs" fails as soon as it finds one
external library that does not exist system-wide (and there's pretty much
bound to be one, given what all kinds of libs we use). So one has to try,
fail, add one --without-system-foo, and repeat until it builds. And try again
with next distro upgrade, or carry a growing list of options.

 Thinking of it, it'd be probably enough if --with-system-libs acted
as --with-system-foo=auto for all such external libs.

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

> Running "./autogen.sh --with-system-libs" fails as soon as it finds
> one external library that does not exist system-wide (and there's pretty
> much bound to be one, given what all kinds of libs we use).

build as an user which does not have additional (local) libraries installed ?

> So one has to try,
> fail, add one --without-system-foo, and repeat until it builds. And
> try again
> with next distro upgrade, or carry a growing list of options.

Distro maintainers have to do the same, potentially for each release.

So, why not just dropping all 3rdparty libs that are included in
mainline distros ?

>  Thinking of it, it'd be probably enough if --with-system-libs acted
> as --with-system-foo=auto for all such external libs.

Such a build (binary image) will likely not be portable to other systems,
as soon as the target system misses some of the libs that existed during
build are not installed on the target system.


cu
--
Mit freundlichen Grüßen / Kind regards

Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development

Äußere Bayreuther Str. 55, D - 90409 Nürnberg
Tel: +49 911 72303-30
Fax: +49 911 72303-50

[hidden email]; www.vnc.de
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tue, 2012-04-24 at 17:16 +0200, Lubos Lunak wrote:
>  Running "./autogen.sh --with-system-libs" fails as soon as it finds one
> external library that does not exist system-wide (and there's pretty much
> bound to be one, given what all kinds of libs we use)

Aha, so I suspect this boils down to "someone put clucene into the
default list of with-system-libs", right :-) ?

C.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Lubos Lunak píše v Út 24. 04. 2012 v 17:16 +0200:
My understanding is that --with-system-libs forces almost all stuff to
be from the system. IMHO, normal developers should not use it. It is
handy for packagers that want to make sure that they use as most system
libraries as possible. It saves the size of package and makes the
security updates easier.

IMHO, if you do not use --with-system-libs, it tries to use the most
typical libraries from system to safe the build time. So, it should give
good results for developers.

If ./autogen.sh without options does not work well, we might discuss
particular defaults. I just wonder what exactly normal developers
explicitly enable/disable.


>  But that doesn't work, that's the point.
>
>  Running "./autogen.sh --with-system-libs" fails as soon as it finds one
> external library that does not exist system-wide (and there's pretty much
> bound to be one, given what all kinds of libs we use). So one has to try,
> fail, add one --without-system-foo, and repeat until it builds. And try again
> with next distro upgrade, or carry a growing list of options.

Well, this is typical also for other software. You usually need to
install several devel packages to make configure happy. Maybe, it was
not problem with KDE but there was the nice "KDE development" package
selection on openSUSE ;-)

Hmm, the was discussed the auto mode. I see two possibilities here:

1. It might enable only features that you could build with your system
   libraries. It might be good that it does not force some stuff if you
   could not build it. On the other hand, it might enable stuff that you
   do not need.

   I do not like it because it is hard to predict what you get. It might
   be more complicated to support all the poor developers with their
   problems.


2. The result of auto mode might be the same set of default features. It
   might just prefer the system stuff when possible and use the internal
   libraries otherwise.

   I kind of like this approach. It might be used to solve the current
   problems with ./autogen.sh without any parameters :-)


Best Regards,
Petr

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Tuesday 24 of April 2012, Caolán McNamara wrote:
> On Tue, 2012-04-24 at 17:16 +0200, Lubos Lunak wrote:
> >  Running "./autogen.sh --with-system-libs" fails as soon as it finds one
> > external library that does not exist system-wide (and there's pretty much
> > bound to be one, given what all kinds of libs we use)
>
> Aha, so I suspect this boils down to "someone put clucene into the
> default list of with-system-libs", right :-) ?

 No, I do have usable CLucene installed. It boils down to "I have to manually
list all libs I don't want to use from system, or all libs I do want to use
from system, or I have to keep rebuilding the bundled copies all the time".

 Re-reading the thread again, it seems to me we're talking about two slightly
different things. What you want is that configure by default builds with the
same set of features enabled, regardless of what system libs are enabled.
Which is the case now, and it is solved by using internal copies of almost
all external libraries. What I want is that configure by default (or at least
easily) uses as many system libs as possible, so that it is not necessary to
keep rebuilding them. That does not conflict with what you want, and that
also does not work now, because in practice one has to manually check every
single library and enable/disable one set of them.

 Is there any reasonable use case for preferring almost all internal copies of
libraries if the system-wide one is suitable? To me it looks like all that
would be needed is making all the --with-system-* options by default work
like 'auto', which would mean using the system library if it is considered
suitable, otherwise use the internal copy. That way the feature set would be
constant, by default developers would get all systems libs they have
available used, Petr would keep using --with-system-libs to use all system
libs except those he has disabled and get a failure if some are not present,
and everybody could tweak what gets used with --with-system-foo if (and only
if) wanted.

 Does somebody see a problem with that? Otherwise I'll do this change or
create an easy hack for it.

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Wed, Apr 25, 2012 at 03:01:16PM +0200, Lubos Lunak wrote:
>  Is there any reasonable use case for preferring almost all internal copies of
> libraries if the system-wide one is suitable?

mu(*). You are asking the wrong question. The problem is that "is suitable" is
not something that is easily decidable. Even less so by configure automagic. It
often boils to making the choice between two sets of bugs (or a set of bugs vs.
one big blocker).

Best,

Bjoern

(*) http://en.wikipedia.org/wiki/Mu_%28negative%29
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Wednesday 25 of April 2012, Bjoern Michaelsen wrote:
> On Wed, Apr 25, 2012 at 03:01:16PM +0200, Lubos Lunak wrote:
> >  Is there any reasonable use case for preferring almost all internal
> > copies of libraries if the system-wide one is suitable?
>
> mu(*). You are asking the wrong question.

 No, I'm not. It's what we do by default, so asking why we do it is a good
question.

> The problem is that "is suitable" is not something that is easily decidable.

 Oh, it is. It either does work, or it does not. If it does not, configure
should bail out. If it does work, whatever my definition of meaning of that
is, then it does work for me.

 This may be more difficult for a packager, but then I'm not a packager.

> Even less so by configure automagic.

 Version checks are so difficult.

> It often boils to making the choice between two sets of bugs (or
> a set of bugs vs. one big blocker).

 The choice has already been made, and it's whatever we ship as our internal
copies.

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

> mu(*). You are asking the wrong question. The problem is that "is
> suitable" is
> not something that is easily decidable. Even less so by configure
> automagic. It
> often boils to making the choice between two sets of bugs (or a set
> of bugs vs.
> one big blocker).

Well, this is a problem of exponential complexity.

The only practically managable way to solve this (given the limited
resources) is leaving this to the distros. They already have their
infrastructures and resources to maintain thousands of packages
in their various combinations. If a project like LO wants to handle
this problem entirely on its own, this essentially means duplicating
such distro infrastructures.

So my clear vote is, dropping all bundled 3rdparty packages,
import them via standard mechanisms (pkg-config, etc) and leave
the rest to the distros.

Now there are several cases to cope with:

a) $distro lacks some packages (unlikely for the major distros)

-> step into the package maintainer role for those packages in
that $distro and provide packages there.

b) $distro doesnt keep up w/ LO upstream fast enough, so users
might miss some features

-> step into the package maintainer role for LO in $distro and
provide newer packages (most of it can be automatized)

note: $distro might have good reasons for being slow at this point
(eg. Ubuntu prefers stability over features). in this case, your
newer LO packages might make it directly into the distro's official
repository, but then we still can maintain our own vendor repository.

c) certain people might want an fully self-contained packages,
for environments that live completely out of any distro context
(mostly: esoteric operating systems, like windows, that don't
even know the fundamental concepts of package management and
distros)
-> roll your own micro-distro
-> set up an build environment (eg. via chroot or sysroot'ed crosscompiler)
that builds all required source packages (along the dependency graph)
and bundles the output to one big binary package, that's going to be
deployed in some different area (on unix-alike platforms that would be
something like /opt/libreoffie/)


In my professional carreer I already had several similar scenarios in
various customer projects. Those who followed my advise, had a mid-
and long-term hr saving in the scale 20..30% (after a few man-weeks
initial efforts for the transition, of course), others who didn't
follow me, still have contigiously increasing maintenance overhead.


cu
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice