Re: distro-configs files, autogen.sh options, defaults etc
On Thu, 2012-04-26 at 11:43 +0200, Petr Mladek wrote: Well, how many internal libraries have an important fix? Just a quick look and I see: Lets discuss this at the ESC call today to avoid excessive bike-shedding :-) it's on the agenda. Thanks, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
Hi, We should not prefer system libraries if the internal copy has an important fix. The interesting question now is: what qualifies an 'important fix' ? IMHO, when the current stable release is really broken. But: in this case, most likely, the distros will clean up the mess anyways, so again we can relax and let the distros do their job. You see that most system libraries should be safe to use. In addition, distro specific packages has to use system libraries because it oreduces maintenance effort, optimizes build and download size. So, the system libraries are tested and should be tested. Why not use them during development? Exactly. I'd suggest doing development/testing on stable releases of various major distros (whichever individuals prefer). We already prefer some system libraries by default: e.g. glibc, BTW: i remeber, several years ago, Oo even shipped its own copy of glibc and gcc ... ;-o libpng, libjpeg? Where is the edge? That's the important question! 2. official TDF release: + need to use as many internal libraries as possible to be usable on different systems = we could solve it by adding --without-system-bla to distro-configs/*.conf; we have beta/rc phase to find bugs here I would prefer dropping that completely from the main codebase, and instead build an separate meta-build layer. Essentially just a shell script that fetches the libs, builds and installs them to some suiteable prefix in the correct order and the builds LO. It would override the standard search pathes (mainly pkg-config tweaking). That script would take the same layer as the distro toolchain in the whole stack. 3. developer builds: + they need all features to make sure that they do not break anything; they do not mind about system libraries; IMHO, the more system libraries, the less potential build problems and the faster build = they will be happy if configure takes systems libraries if they are available by default I would prefer when it *only* takes a bundled library, if I explicitly force it to do so for some damn good reason. 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 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
Lubos Lunak píše v Út 24. 04. 2012 v 17:16 +0200: On Tuesday 24 of April 2012, Caolán McNamara wrote: On Tue, 2012-04-24 at 11:49 +0200, Lubos Lunak wrote: 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 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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
On 04/25/2012 05:05 PM, Lubos Lunak wrote: The choice has already been made, and it's whatever we ship as our internal ...more or less intensively patched... copies. (At least, this was a real problem in the past, when people thought they could replace LO's -- or, back then, OOo's rather -- copies with stock instances, where the former often had specific fixes that either -- for whatever reason -- where not upstreamed at all, or nobody had bothered to actually do a proper version check for in configure. I would hope this has improved over time, though.) Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
(*) While this can (and did) happen just by changes in the package itself, automagically toggling configure-output is severly raising the risk. ACK. Build processes should be as predictable and deterministic as possible. Optimally, it should be a function (in mathematical terms) with as few parameters as possible. Things like automatic dependency switching - IOW: automatically switching on/off certain features or linking in certain libraries just by their precense in the building system - is quite dangerous as soon as that build result is put to another system. You neither can rely on a specific feature set (installing or removing one library in the building system may magically change the build output), nor can you know which libraries are actually required at runtime (without deeper analysis of the actual build output). Such behaviour is a nightmare for distro maintainers. cu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
2012/4/24 Bjoern Michaelsen bjoern.michael...@canonical.com: 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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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? 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*. 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 l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 pgpIgBQKiIbnN.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
On Tuesday 24 of April 2012, Caolán McNamara wrote: On Tue, 2012-04-24 at 11:49 +0200, Lubos Lunak wrote: 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 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 l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: distro-configs files, autogen.sh options, defaults etc
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
