Re: A first try to remove some copyleft components from the build
On Mon, Jul 18, 2011 at 1:14 PM, Mathias Bauer wrote: > > I wanted to have it lazy ;-), so I just added a single configure switch > "--with-disable-copyleft" and did some quick and dirty changes to > configure.in. If someone wants to make the name or the implementation > nicer - please go for it. I never got when to use "yes/no" or > "true/false" in our configure.in. :-) If I read this correctly, you have this switch backwards. Copyleft needs to be opt-in, not opt-out. - Sam Ruby
Re: A first try to remove some copyleft components from the build
On 18.07.2011 19:29, Sam Ruby wrote: > On Mon, Jul 18, 2011 at 1:14 PM, Mathias Bauer wrote: >> >> I wanted to have it lazy ;-), so I just added a single configure switch >> "--with-disable-copyleft" and did some quick and dirty changes to >> configure.in. If someone wants to make the name or the implementation >> nicer - please go for it. I never got when to use "yes/no" or >> "true/false" in our configure.in. :-) > > If I read this correctly, you have this switch backwards. Copyleft > needs to be opt-in, not opt-out. > > - Sam Ruby > Yes, that's for practical reasons, otherwise I had to rewrite larger parts of configure.in. Once the build works with this switch in all places, it's a better time to do this rewrite. Thanks for the remark, I totally forgot to mention this. Regards, Mathias
Re: A first try to remove some copyleft components from the build
Hello Mathias; --- On Mon, 7/18/11, Mathias Bauer wrote: > Hi, > > I tried to get rid of some copyleft dependencies. As I will > leave for vacation on Wednesday, First of all, thanks so much for working on this! > I now send my first patch to the list so that others already > can have a look or even continue. I only did it on Linux so > far, of course we will need adaptions for other platforms. Not too many :-). > I created the patch from the hg repository of > OpenOffice.org, but the > differences to our still not existing svn repository won't > be huge, so > it should bring us a little bit closer to a "clean" build. > > I also added some more todos to the wiki page. > > Meanwhile the license information at > > http://wiki.services.openoffice.org/wiki/ApacheMigration > I would like to add a couple more: 1) xpdf (GPL'd) is a run dependency, this is linux/unix specific. PDFBox may be a replacement. 2) The build requires GNU cp, which is inconvenient for the BSDs and MacOS X: http://lists.freedesktop.org/archives/libreoffice/2010-October/000586.html cheers, Pedro.
Re: A first try to remove some copyleft components from the build
On 18.07.2011 20:04, Pedro F. Giffuni wrote: > Hello Mathias; > > --- On Mon, 7/18/11, Mathias Bauer wrote: >> Hi, >> >> I tried to get rid of some copyleft dependencies. As I will >> leave for vacation on Wednesday, > > First of all, thanks so much for working on this! > >> I now send my first patch to the list so that others already >> can have a look or even continue. I only did it on Linux so >> far, of course we will need adaptions for other platforms. > > Not too many :-). > >> I created the patch from the hg repository of >> OpenOffice.org, but the >> differences to our still not existing svn repository won't >> be huge, so >> it should bring us a little bit closer to a "clean" build. >> >> I also added some more todos to the wiki page. >> >> Meanwhile the license information at >> >> http://wiki.services.openoffice.org/wiki/ApacheMigration >> > > I would like to add a couple more: > > 1) xpdf (GPL'd) is a run dependency, this is linux/unix > specific. PDFBox may be a replacement. This component is used for the pdf import extension, not for OOo itself. The pdf import extension is not built by default, there is a configure switch to enable it in the build. In that case xpdf would be required. I think that this already fulfils the legal requirements that building lgpl code must be "opt-in". So as far as I can see, this is not a "to do". > > 2) The build requires GNU cp, which is inconvenient for > the BSDs and MacOS X: > http://lists.freedesktop.org/archives/libreoffice/2010-October/000586.html I remember a lot of discussions around different ways to copy files in the new build system of OOo. We can revive that and see where it brings us. Nevertheless, I think that discussing GNU cp will happen on usability grounds, not caused by legal requirements. I added this to the todo list. Regards, Mathias
Re: A first try to remove some copyleft components from the build
On 18.07.2011 20:21, Mathias Bauer wrote: >> 1) xpdf (GPL'd) is a run dependency, this is linux/unix >> specific. PDFBox may be a replacement. > > This component is used for the pdf import extension, not for OOo itself. > > The pdf import extension is not built by default, there is a configure > switch to enable it in the build. In that case xpdf would be required. I > think that this already fulfils the legal requirements that building > lgpl code must be "opt-in". So as far as I can see, this is not a "to do". Giving it one more thought: it would be still a to do if we wanted to have a pdf import extension released by Apache. So perhaps a to do with minor priority. Regards, Mathias
Re: A first try to remove some copyleft components from the build
Hi *, On Mon, Jul 18, 2011 at 8:04 PM, Pedro F. Giffuni wrote: > > 1) xpdf (GPL'd) is a run dependency, this is linux/unix > specific. PDFBox may be a replacement. Why would this be linux/unix specific? xpdf code is used for the pdf-import extension, and that is available for Windows as well. > 2) The build requires GNU cp, which is inconvenient for > the BSDs and MacOS X: You don't need GNU cp to build on Mac. > http://lists.freedesktop.org/archives/libreoffice/2010-October/000586.html You should have read the initial message, or the current situation. If you use --disable-build-mozilla / --disable-mozilla, you only need XCode on Mac, no other external stuff. (unless you're on 10.4, then you also need gnu make >= 3.81) When building mozilla (nowadays actually seamonkey, but the configure switch remained the same), you need libIDL and its dependencies in addition (glib, gettext, and pkg-config for convenience) ciao Christian
Re: A first try to remove some copyleft components from the build
--- On Mon, 7/18/11, Mathias Bauer wrote: ... > > > > I would like to add a couple more: > > > > 1) xpdf (GPL'd) is a run dependency, this is > > linux/unix specific. PDFBox may be a replacement. > > This component is used for the pdf import extension, not > for OOo itself. > > The pdf import extension is not built by default, there is > a configure switch to enable it in the build. In that case > xpdf would be required. I think that this already fulfils > the legal requirements that building lgpl code must be > "opt-in". So as far as I can see, this is not a "to do". > OK, that's fair. I do think it's convenient since I doubt xpdf is portable beyond unix. FWIW, while looking at PDFBox and it's dependencies, I became acquainted with the Legion of the Bouncy Castle: http://www.bouncycastle.org/ A possible replacement for NSS if you don't care it's Java. > > > > 2) The build requires GNU cp, which is inconvenient > > for the BSDs and MacOS X: ... > Nevertheless, I think that discussing GNU cp will > happen on usability grounds, not caused by legal > requirements. I added this to the todo list. > Thanks. I agree it's a usability issue, but just to put this in context, it involves rebuilding all the GNU coreutils package as a requisite for building OpenOffice, which brings not only extra build time, but also leaves a lot of bloat: basename, cat, chgrp, chmod, chown, chroot, cksum, comm, cp, csplit, cut, date, dd, df, dir, dircolors, dirname, du, echo, env, expand, expr, factor, false, fmt, fold, groups, head, hostid, hostname, id, install, join, kill, link, ln, logname, ls, md5sum, mkdir, mkfifo, mknod, mv, nice, nl, nohup, od, paste, pathchk, pinky, pr, printenv, printf, ptx, pwd, readlink, rm, rmdir, seq, sha1sum, shred, sleep, sort, split, stat, stty, su, sum, sync, tac, tail, tee, test, touch, tr, true, tsort, tty, uname, unexpand, uniq, unlink, uptime, users, vdir, wc, who, whoami, yes It is worse than bash! (sorry for the rant .. I know it's not your fault :) ) Pedro.
Re: A first try to remove some copyleft components from the build
--- On Mon, 7/18/11, Christian Lohmaier wrote: > On Mon, Jul 18, 2011 at 8:04 PM, Pedro F. Giffuni > wrote: > > > > 1) xpdf (GPL'd) is a run dependency, this is > > linux/unix specific. PDFBox may be a replacement. > > Why would this be linux/unix specific? xpdf code is used > for the pdf-import extension, and that is available for > Windows as well. > My bad, sorry. I thought the X referred to the windowing system. > > 2) The build requires GNU cp, which is inconvenient > > for the BSDs and MacOS X: > > You don't need GNU cp to build on Mac. > GNU cp appears as a build dependency for FreeBSD's OpenOffice 3.4 (devel) port. Should I try building without it? cheers, Pedro.
Re: A first try to remove some copyleft components from the build
Mathias Bauer wrote: > On 18.07.2011 20:21, Mathias Bauer wrote: > >>> 1) xpdf (GPL'd) is a run dependency, this is linux/unix >>> specific. PDFBox may be a replacement. >> >> This component is used for the pdf import extension, not for OOo itself. >> >> The pdf import extension is not built by default, there is a configure >> switch to enable it in the build. In that case xpdf would be required. I >> think that this already fulfils the legal requirements that building >> lgpl code must be "opt-in". So as far as I can see, this is not a "to do". > > Giving it one more thought: it would be still a to do if we wanted to > have a pdf import extension released by Apache. So perhaps a to do with > minor priority. > > Regards, > Mathias If we do include the pdf import extension I would like to see it rewritten to do a better job of importing. I have seen to many post in the forums about the way that it works. My suggestion would be to drop it completely. Andy
Re: A first try to remove some copyleft components from the build
On 18/07/11 20:50, Andy Brown wrote: Mathias Bauer wrote: On 18.07.2011 20:21, Mathias Bauer wrote: 1) xpdf (GPL'd) is a run dependency, this is linux/unix specific. PDFBox may be a replacement. This component is used for the pdf import extension, not for OOo itself. The pdf import extension is not built by default, there is a configure switch to enable it in the build. In that case xpdf would be required. I think that this already fulfils the legal requirements that building lgpl code must be "opt-in". So as far as I can see, this is not a "to do". Giving it one more thought: it would be still a to do if we wanted to have a pdf import extension released by Apache. So perhaps a to do with minor priority. Regards, Mathias If we do include the pdf import extension I would like to see it rewritten to do a better job of importing. I have seen to many post in the forums about the way that it works. My suggestion would be to drop it completely. Andy A lot of the issues I see on the forum regarding the PDF extension are to do with expectation. People seem to think this extension is going to give them a full-blown PDF editor with the capabilities of the Adobe tools. When they discover it is for tiny corrections and typo fixes they feel let down. That's not to say there aren't any bugs in it, there may well be. But I don;t think the PDF extension was positioned or described sufficiently to provide users with the correct expectations. Dave.
Re: A first try to remove some copyleft components from the build
On 18.07.2011 21:28, Pedro F. Giffuni wrote: > --- On Mon, 7/18/11, Christian Lohmaier wrote: > >> On Mon, Jul 18, 2011 at 8:04 PM, Pedro F. Giffuni >> wrote: >> > >> > 1) xpdf (GPL'd) is a run dependency, this is >> > linux/unix specific. PDFBox may be a replacement. >> >> Why would this be linux/unix specific? xpdf code is used >> for the pdf-import extension, and that is available for >> Windows as well. >> > > My bad, sorry. I thought the X referred to the windowing > system. > >> > 2) The build requires GNU cp, which is inconvenient >> > for the BSDs and MacOS X: >> >> You don't need GNU cp to build on Mac. >> > > GNU cp appears as a build dependency for FreeBSD's > OpenOffice 3.4 (devel) port. Should I try building > without it? Sorry, I don't remember exactly. Perhaps after my vacation. :-) Regards, Mathias
Re: A first try to remove some copyleft components from the build
David McKay wrote: > > On 18/07/11 20:50, Andy Brown wrote: >> Mathias Bauer wrote: >>> On 18.07.2011 20:21, Mathias Bauer wrote: >>> > 1) xpdf (GPL'd) is a run dependency, this is linux/unix > specific. PDFBox may be a replacement. This component is used for the pdf import extension, not for OOo itself. The pdf import extension is not built by default, there is a configure switch to enable it in the build. In that case xpdf would be required. I think that this already fulfils the legal requirements that building lgpl code must be "opt-in". So as far as I can see, this is not a "to do". >>> Giving it one more thought: it would be still a to do if we wanted to >>> have a pdf import extension released by Apache. So perhaps a to do with >>> minor priority. >>> >>> Regards, >>> Mathias >> If we do include the pdf import extension I would like to see it >> rewritten to do a better job of importing. I have seen to many post in >> the forums about the way that it works. My suggestion would be to drop >> it completely. >> >> Andy >> > A lot of the issues I see on the forum regarding the PDF extension are > to do with expectation. People seem to think this extension is going to > give them a full-blown PDF editor with the capabilities of the Adobe > tools. When they discover it is for tiny corrections and typo fixes they > feel let down. That's not to say there aren't any bugs in it, there may > well be. But I don;t think the PDF extension was positioned or described > sufficiently to provide users with the correct expectations. > > Dave. I agree with you that it is the expectations that cause the real problem. For me it is a waste as it does not do as most people expect. An OCR import would be a better option, if we can find one. Andy
Re: A first try to remove some copyleft components from the build
Am 07/18/2011 10:04 PM, schrieb David McKay: On 18/07/11 20:50, Andy Brown wrote: Mathias Bauer wrote: On 18.07.2011 20:21, Mathias Bauer wrote: 1) xpdf (GPL'd) is a run dependency, this is linux/unix specific. PDFBox may be a replacement. This component is used for the pdf import extension, not for OOo itself. The pdf import extension is not built by default, there is a configure switch to enable it in the build. In that case xpdf would be required. I think that this already fulfils the legal requirements that building lgpl code must be "opt-in". So as far as I can see, this is not a "to do". Giving it one more thought: it would be still a to do if we wanted to have a pdf import extension released by Apache. So perhaps a to do with minor priority. Regards, Mathias If we do include the pdf import extension I would like to see it rewritten to do a better job of importing. I have seen to many post in the forums about the way that it works. My suggestion would be to drop it completely. Andy A lot of the issues I see on the forum regarding the PDF extension are to do with expectation. People seem to think this extension is going to give them a full-blown PDF editor with the capabilities of the Adobe tools. When they discover it is for tiny corrections and typo fixes they feel let down. That's not to say there aren't any bugs in it, there may well be. But I don;t think the PDF extension was positioned or described sufficiently to provide users with the correct expectations. The intension was to show what is possible. On the extension website is a note that the Beta status was left due to the positive notes we got about the extension. But this is no promiss that its quality is like the import filter for the documents formats for MS Word & Co. The solution is not to remove the extension but to improve it's work. Marcus
Re: A first try to remove some copyleft components from the build
Marcus (OOo) wrote: > Am 07/18/2011 10:04 PM, schrieb David McKay: >> >> On 18/07/11 20:50, Andy Brown wrote: >>> Mathias Bauer wrote: On 18.07.2011 20:21, Mathias Bauer wrote: >> 1) xpdf (GPL'd) is a run dependency, this is linux/unix >> specific. PDFBox may be a replacement. > This component is used for the pdf import extension, not for OOo > itself. > > The pdf import extension is not built by default, there is a configure > switch to enable it in the build. In that case xpdf would be > required. I > think that this already fulfils the legal requirements that building > lgpl code must be "opt-in". So as far as I can see, this is not a > "to do". Giving it one more thought: it would be still a to do if we wanted to have a pdf import extension released by Apache. So perhaps a to do with minor priority. Regards, Mathias >>> If we do include the pdf import extension I would like to see it >>> rewritten to do a better job of importing. I have seen to many post in >>> the forums about the way that it works. My suggestion would be to drop >>> it completely. >>> >>> Andy >>> >> A lot of the issues I see on the forum regarding the PDF extension are >> to do with expectation. People seem to think this extension is going to >> give them a full-blown PDF editor with the capabilities of the Adobe >> tools. When they discover it is for tiny corrections and typo fixes they >> feel let down. That's not to say there aren't any bugs in it, there may >> well be. But I don;t think the PDF extension was positioned or described >> sufficiently to provide users with the correct expectations. > > The intension was to show what is possible. On the extension website is > a note that the Beta status was left due to the positive notes we got > about the extension. But this is no promiss that its quality is like the > import filter for the documents formats for MS Word & Co. > > The solution is not to remove the extension but to improve it's work. > > Marcus > If it can be improved then it maybe worth the effort. I still think an OCR engine would do the work. Andy
Re: A first try to remove some copyleft components from the build
On Tue, Jul 19, 2011 at 12:54 AM, Andy Brown wrote: > Marcus (OOo) wrote: > > Am 07/18/2011 10:04 PM, schrieb David McKay: > >> > >> On 18/07/11 20:50, Andy Brown wrote: > >>> Mathias Bauer wrote: > On 18.07.2011 20:21, Mathias Bauer wrote: > > >> 1) xpdf (GPL'd) is a run dependency, this is linux/unix > >> specific. PDFBox may be a replacement. > > This component is used for the pdf import extension, not for OOo > > itself. > > > > The pdf import extension is not built by default, there is a > configure > > switch to enable it in the build. In that case xpdf would be > > required. I > > think that this already fulfils the legal requirements that building > > lgpl code must be "opt-in". So as far as I can see, this is not a > > "to do". > Giving it one more thought: it would be still a to do if we wanted to > have a pdf import extension released by Apache. So perhaps a to do > with > minor priority. > > Regards, > Mathias > >>> If we do include the pdf import extension I would like to see it > >>> rewritten to do a better job of importing. I have seen to many post in > >>> the forums about the way that it works. My suggestion would be to drop > >>> it completely. > >>> > >>> Andy > >>> > >> A lot of the issues I see on the forum regarding the PDF extension are > >> to do with expectation. People seem to think this extension is going to > >> give them a full-blown PDF editor with the capabilities of the Adobe > >> tools. When they discover it is for tiny corrections and typo fixes they > >> feel let down. That's not to say there aren't any bugs in it, there may > >> well be. But I don;t think the PDF extension was positioned or described > >> sufficiently to provide users with the correct expectations. > > > > The intension was to show what is possible. On the extension website is > > a note that the Beta status was left due to the positive notes we got > > about the extension. But this is no promiss that its quality is like the > > import filter for the documents formats for MS Word & Co. > > > > The solution is not to remove the extension but to improve it's work. > > > > Marcus > > > > If it can be improved then it maybe worth the effort. I still think an > OCR engine would do the work. > i think if we can fix the legal issues with the dependencies we should keep it and maybe somebody will work on it. It provides at least a minimal import which is not enough for some people but is good enough for many others. It's always the same that you hear more concerns than positive feedback. And if somebody will develop something on OCR it's even better and we get a further enhancement... Juergen > > Andy >
Re: A first try to remove some copyleft components from the build
On Mon, Jul 18, 2011 at 7:14 PM, Mathias Bauer wrote: > Hi, > > I tried to get rid of some copyleft dependencies. As I will leave for > vacation on Wednesday, I now send my first patch to the list so that > others already can have a look or even continue. I only did it on Linux > so far, of course we will need adaptions for other platforms. > I created the patch from the hg repository of OpenOffice.org, but the > differences to our still not existing svn repository won't be huge, so > it should bring us a little bit closer to a "clean" build. > > I also added some more todos to the wiki page. > > Meanwhile the license information at > > http://wiki.services.openoffice.org/wiki/ApacheMigration > > about our external tarballs is nearly complete, so there might be some > more modules that could be worked on before we will tackle the > "internal" copyleft dependencies. As I see it, I already should have > covered most dependencies on copyleft licensed external tarballs, with > the exceptions of the modules for the svg import (Kai Ahrens announced > to work on it) and linear solver (Niklas Nebel already created a first > patch for it). > > Now some words about the patch. > > I wanted to have it lazy ;-), so I just added a single configure switch > "--with-disable-copyleft" and did some quick and dirty changes to > configure.in. If someone wants to make the name or the implementation > nicer - please go for it. I never got when to use "yes/no" or > "true/false" in our configure.in. :-) > > With the changes in the patch the following modules won't be built > anymore when the switch is used: > > dictionaries > epm > gstreamer > hunspell > hyphen > libwpd > mozilla > mythes > neon > nss > saxon > > and some modules or module parts that depend on them. I didn't need to > remove any sources, as all copyleft parts that I removed are external > tar balls. The code using these parts is just "normal" OOo code that can > stay in the repository, though should be left out in the standard build > at Apache. > > The final installation set of the build on Linux currently ist just > created as a tar.gz, native packages can't be created as epm is missing. > (I already posted a question about epm to this list, hopefully someone > will be able to answer it.) Thus the build currently finishes with an > error message, nevertheless the tar.gz was created and the result > basically runs fine. > > The patch contains some unfinished work in rhino that is still commented > out. If someone knows how to add conditional compilation to a build.xml > file (I don't): the module "scripting" has parts depending on rhino that > need to be removed from the build.xml in case DISABLE_RHINO is set. > Which parts these are can easily be "detected" (means: found by build > breakages) by removing the comment signs from my changes in rhino before > you start the build. > > If you want to try it yourself: get the source from > http://hg.services.openoffice.org/OOO340, apply the patch, call autoconf > and then do the build as usual, following the build instructions in the > ooo wiki. On my Ubuntu 11.04 the new configure switch was the only one I > needed. > i will try it under MacOS but i will also take a short break over the weekend By the way well done Mathias it brings us forward Juergen > > For those amongst us that are used to the OOo build system: I treated > configure no longer as part of the build tree, so autoconf is required > after applying the patch. Makes more sense that way, IMHO, and from what > I already learned on this list, it is the preferred way at Apache. > > Regards, > Mathias >
Re: A first try to remove some copyleft components from the build
Hi Mathias, On Monday, 2011-07-18 19:14:46 +0200, Mathias Bauer wrote: > I wanted to have it lazy ;-), so I just added a single configure switch > "--with-disable-copyleft" and did some quick and dirty changes to > configure.in. Well, that resulted in copyleft always disabled ;-) because in if test "$with-disable-copyleft" != ""; then the expression is always true as "-disable-copyleft" appended to $with is a non-empty string.. that would had to use "$with_disable_copyleft" instead. > If someone wants to make the name or the implementation > nicer - please go for it. I never got when to use "yes/no" or > "true/false" in our configure.in. :-) --with-... options take any argument, for example a path where a library can be found. --enable-.../--disable-... indeed sometimes evaluate both, yes/no and true/false, but many places only check for yes/no, to me that's sufficient. I changed the option to --enable-copyleft with yes/no, defaulting to empty == no. I also provided empty sets for the variables so invoking configure --enable-copyleft from an already set environment produces the desired results. Attached are on_top_of_mba.diff with only the changes to the previous version one can apply on top, and aooo_disable_copyleft.diff with the merged patches. Don't forget to run autoconf when applied. Builds fine on Debian Squeeze unxlngx6.pro, but I didn't get any install set, not even a .tar.gz, this helped: cd $SRC_ROOT/instsetoo_native/util dmake openoffice_en-US PKGFORMAT=installed Smoketest worked, except one message: Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so: cannot open shared object file: No such file or directory Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD # HG changeset patch # Parent a5a03f67e2623c6756aa42f2eaa84566d9a8f5b0 really make copylefts an option diff --git a/configure.in b/configure.in --- a/configure.in +++ b/configure.in @@ -842,8 +842,8 @@ AC_ARG_ENABLE(verbose, AC_ARG_ENABLE(dependency-tracking, [ --disable-dependency-tracking Disables generation of dependency information. ],,) -AC_ARG_WITH(disable-copyleft, -[ --with-disable-copyleftWhether to use provided NSS module +AC_ARG_ENABLE(copyleft, +[ --enable-copyleft Whether to use copyleft components. ],,) BUILD_TYPE="OOo" @@ -1231,8 +1231,8 @@ dnl dnl Build options dnl === -AC_MSG_CHECKING([whether to disable copyleft components]) -if test "$with-disable-copyleft" != ""; then +AC_MSG_CHECKING([whether to enable copyleft components]) +if test "$enable_copyleft" != "yes"; then enable_mozilla="no" enable_nss_module="no" @@ -1245,17 +1245,29 @@ if test "$with-disable-copyleft" != ""; DISABLE_HYPHEN="TRUE" DISABLE_LIBWPD="TRUE" DISABLE_SAXON="TRUE" + DISABLE_NEON="TRUE" BUILD_EPM="NO" -AC_MSG_RESULT([yes]) - + AC_MSG_RESULT([yes]) + +else + + DISABLE_HUNSPELL= + DISABLE_HYPHEN= + DISABLE_LIBWPD= + DISABLE_SAXON= + DISABLE_NEON= + + AC_MSG_RESULT([no]) + +fi AC_SUBST(DISABLE_HUNSPELL) AC_SUBST(DISABLE_HYPHEN) AC_SUBST(DISABLE_LIBWPD) AC_SUBST(DISABLE_SAXON) +AC_SUBST(DISABLE_NEON) AC_SUBST(BUILD_EPM) -fi AC_MSG_CHECKING([whether to enable native CUPS support]) if test "$test_cups" = "yes" -a \( "$enable_cups" = "yes" -o "$enable_cups" = "TRUE" \) ; then @@ -3652,7 +3664,7 @@ AC_SUBST(SYSTEM_EXPAT) dnl === dnl Check for system libwpd dnl === -if test "with-disable-copyleft" == ""; then +if test -n "$enable_copyleft" -a "$enable_copyleft" != "no"; then AC_MSG_CHECKING([which libwpd to use]) if test -n "$with_system_libwpd" -o -n "$with_system_libs" && \ test "$with_system_libwpd" != "no"; then @@ -4125,7 +4137,7 @@ AC_SUBST(BSH_JAR) dnl === dnl Check for system saxon dnl === -if test "with-disable-copyleft" == ""; then +if test -n "$enable_copyleft" -a "$enable_copyleft" != "no"; then AC_MSG_CHECKING([which saxon to use]) if test -n "$with_system_saxon" -o -n "$with_system_libs" && \ test "$with_system_saxon" != "no" && test "$with_system_jars" != "no"; then @@ -5129,7 +5141,7 @@ dnl dnl Check for system hunspell dnl === -if test "with-disable-copyleft" == ""; then +if test -n "$enable_copyleft" -a "$enable_copyleft" != "no"; then AC_MSG_CHECKING([which libhunspell to use]) if test -n "$with_system_hunspell" -o -n "$with_system_libs" && \ # HG changeset patch # Parent c904c194446275403ad0332f003072ea4d39cc12 * * * really ma
Re: A first try to remove some copyleft components from the build
Hi Eike, thanks a lot for your improvements! On 19.07.2011 23:21, Eike Rathke wrote: > Hi Mathias, > > On Monday, 2011-07-18 19:14:46 +0200, Mathias Bauer wrote: > >> I wanted to have it lazy ;-), so I just added a single configure switch >> "--with-disable-copyleft" and did some quick and dirty changes to >> configure.in. > > Well, that resulted in copyleft always disabled ;-) because in > > if test "$with-disable-copyleft" != ""; then > > the expression is always true as "-disable-copyleft" appended to $with > is a non-empty string.. that would had to use "$with_disable_copyleft" > instead. Ah, yes. Good catch. >> If someone wants to make the name or the implementation >> nicer - please go for it. I never got when to use "yes/no" or >> "true/false" in our configure.in. :-) > > --with-... options take any argument, for example a path where a library > can be found. --enable-.../--disable-... indeed sometimes evaluate both, > yes/no and true/false, but many places only check for yes/no, to me > that's sufficient. > > I changed the option to --enable-copyleft with yes/no, defaulting to > empty == no. That's what Sam asked for. I thought that this makes configure switches a little bit inconsistent, as now switches like "disable-mozilla" can be used only in conjunction with enable-copyleft. I thought that then configure.in should get a larger rewrite so that all stuff that is disabled by the new switch should get "enable" switches and not "disable" switches. But now when I see your changes I agree with them and think that we can rewrite the configure logic later. > Builds fine on Debian Squeeze unxlngx6.pro, but I didn't get any install > set, not even a .tar.gz, this helped: > > cd $SRC_ROOT/instsetoo_native/util > dmake openoffice_en-US PKGFORMAT=installed Interesting, I got the tar.gzbuilt on Ubuntu. Maybe your changes caused the difference? It's important that EPM is not disabled as the stupid instsetoo_native module does not do anything in that case though it could create the tar.gz without problems. Regards, Mathias
Re: A first try to remove some copyleft components from the build
Hi Mathias, On Tuesday, 2011-07-19 23:32:50 +0200, Mathias Bauer wrote: > > Builds fine on Debian Squeeze unxlngx6.pro, but I didn't get any install > > set, not even a .tar.gz, this helped: > > > > cd $SRC_ROOT/instsetoo_native/util > > dmake openoffice_en-US PKGFORMAT=installed > > Interesting, I got the tar.gzbuilt on Ubuntu. Maybe your changes caused > the difference? It's important that EPM is not disabled as the stupid > instsetoo_native module does not do anything in that case though it > could create the tar.gz without problems. Um, probably because epm wasn't installed on my machine.. I installed and reconfigured, but still.. A few minutes later: the patch sets enable_epm="no", removing that works, but that may be no real solution because later on BUILD_EPM may be set to YES if epm is enabled and no system epm was found, I didn't try that. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpLis5pBGgPb.pgp Description: PGP signature
Re: A first try to remove some copyleft components from the build
Wrt PDF Import Extension, and similar extensions: Optional extensions should not be part of a regular OOo build or source tree, IMHO. We should have separate source trees for the core product, and for optional extensions. Malte. On 18.07.2011 20:21, Mathias Bauer wrote: On 18.07.2011 20:04, Pedro F. Giffuni wrote: Hello Mathias; --- On Mon, 7/18/11, Mathias Bauer wrote: Hi, I tried to get rid of some copyleft dependencies. As I will leave for vacation on Wednesday, First of all, thanks so much for working on this! I now send my first patch to the list so that others already can have a look or even continue. I only did it on Linux so far, of course we will need adaptions for other platforms. Not too many :-). I created the patch from the hg repository of OpenOffice.org, but the differences to our still not existing svn repository won't be huge, so it should bring us a little bit closer to a "clean" build. I also added some more todos to the wiki page. Meanwhile the license information at http://wiki.services.openoffice.org/wiki/ApacheMigration I would like to add a couple more: 1) xpdf (GPL'd) is a run dependency, this is linux/unix specific. PDFBox may be a replacement. This component is used for the pdf import extension, not for OOo itself. The pdf import extension is not built by default, there is a configure switch to enable it in the build. In that case xpdf would be required. I think that this already fulfils the legal requirements that building lgpl code must be "opt-in". So as far as I can see, this is not a "to do". 2) The build requires GNU cp, which is inconvenient for the BSDs and MacOS X: http://lists.freedesktop.org/archives/libreoffice/2010-October/000586.html I remember a lot of discussions around different ways to copy files in the new build system of OOo. We can revive that and see where it brings us. Nevertheless, I think that discussing GNU cp will happen on usability grounds, not caused by legal requirements. I added this to the todo list. Regards, Mathias
Re: A first try to remove some copyleft components from the build
On 20.07.2011 13:06, Eike Rathke wrote: Hi Mathias, On Tuesday, 2011-07-19 23:32:50 +0200, Mathias Bauer wrote: Builds fine on Debian Squeeze unxlngx6.pro, but I didn't get any install set, not even a .tar.gz, this helped: cd $SRC_ROOT/instsetoo_native/util dmake openoffice_en-US PKGFORMAT=installed Interesting, I got the tar.gzbuilt on Ubuntu. Maybe your changes caused the difference? It's important that EPM is not disabled as the stupid instsetoo_native module does not do anything in that case though it could create the tar.gz without problems. Um, probably because epm wasn't installed on my machine.. I installed and reconfigured, but still.. A few minutes later: the patch sets enable_epm="no", removing that works, but that may be no real solution because later on BUILD_EPM may be set to YES if epm is enabled and no system epm was found, I didn't try that. It's only a short time solution to be able to test the result of the build. Later on we have to find out whether it is OK to use EPM for packaging and adjust configure.in accordingly (we would make installing EPM a requirement then, just like installing a compiler or other things). I hope that someone is able to answer my question regarding EPM. Regards, Mathias
Re: A first try to remove some copyleft components from the build
Wrt PDF Import Extension, and similar extensions: Optional extensions should not be part of a regular OOo build or source tree, IMHO. We should have separate source trees for the core product, and for optional extensions. Malte. On 18.07.2011 20:21, Mathias Bauer wrote: On 18.07.2011 20:04, Pedro F. Giffuni wrote: Hello Mathias; --- On Mon, 7/18/11, Mathias Bauer wrote: Hi, I tried to get rid of some copyleft dependencies. As I will leave for vacation on Wednesday, First of all, thanks so much for working on this! I now send my first patch to the list so that others already can have a look or even continue. I only did it on Linux so far, of course we will need adaptions for other platforms. Not too many :-). I created the patch from the hg repository of OpenOffice.org, but the differences to our still not existing svn repository won't be huge, so it should bring us a little bit closer to a "clean" build. I also added some more todos to the wiki page. Meanwhile the license information at http://wiki.services.openoffice.org/wiki/ApacheMigration I would like to add a couple more: 1) xpdf (GPL'd) is a run dependency, this is linux/unix specific. PDFBox may be a replacement. This component is used for the pdf import extension, not for OOo itself. The pdf import extension is not built by default, there is a configure switch to enable it in the build. In that case xpdf would be required. I think that this already fulfils the legal requirements that building lgpl code must be "opt-in". So as far as I can see, this is not a "to do". 2) The build requires GNU cp, which is inconvenient for the BSDs and MacOS X: http://lists.freedesktop.org/archives/libreoffice/2010-October/000586.html I remember a lot of discussions around different ways to copy files in the new build system of OOo. We can revive that and see where it brings us. Nevertheless, I think that discussing GNU cp will happen on usability grounds, not caused by legal requirements. I added this to the todo list. Regards, Mathias
Re: A first try to remove some copyleft components from the build
--- On Fri, 7/22/11, Malte Timmermann wrote: > Wrt PDF Import Extension, and similar extensions: Optional > extensions should not be part of a regular OOo build or > source tree, > IMHO. > In general, I agree, however a pdf import extension (with OCR) would be popular enough that we should include it by default. This is in concordance with our ability to produce pdf's which has been one or the real advantages of OOo wrt to the leading commercial competitor. It has to work very well first though. cheers, Pedro.
Re: A first try to remove some copyleft components from the build
Having extensions separated from the source tree of the core product doesn't mean they can't be part of some installation set. This is just about packaging then. Malte. On 22.07.2011 17:11, Pedro F. Giffuni wrote: --- On Fri, 7/22/11, Malte Timmermann wrote: Wrt PDF Import Extension, and similar extensions: Optional extensions should not be part of a regular OOo build or source tree, IMHO. In general, I agree, however a pdf import extension (with OCR) would be popular enough that we should include it by default. This is in concordance with our ability to produce pdf's which has been one or the real advantages of OOo wrt to the leading commercial competitor. It has to work very well first though. cheers, Pedro.
Re: A first try to remove some copyleft components from the build
--- On Sat, 7/23/11, Malte Timmermann wrote: > Having extensions separated from the > source tree of the core product > doesn't mean they can't be part of some installation set. > > This is just about packaging then. > Having the extensions in the same tarball usually makes packaging easier, and as long as "configure" makes it easy to enable/disabling them there shouldn't be any problem. I don't see good reasons for separating extensions unless there are license issues or someone wants to make extensive development, and in this last case Apache can have sub-projects (like PyLucene). I guess there might be special cases, but we will have to wait until we have a first build to look at that. cheers, Pedro. > Malte. > > On 22.07.2011 17:11, Pedro F. Giffuni wrote: > > > > --- On Fri, 7/22/11, Malte Timmermann > wrote: > > > > > >> Wrt PDF Import Extension, and similar extensions: > Optional > >> extensions should not be part of a regular OOo > build or > >> source tree, > >> IMHO. > >> > > > > In general, I agree, however a pdf import extension > (with OCR) > > would be popular enough that we should include it by > default. > > This is in concordance with our ability to produce > pdf's which > > has been one or the real advantages of OOo wrt to the > leading > > commercial competitor. > > > > It has to work very well first though. > > > > cheers, > > > > Pedro. > > > > i.
OCR (was Re: A first try to remove some copyleft components from the build)
FWIW; --- On Mon, 7/18/11, Andy Brown wrote: ... > > I agree with you that it is the expectations that cause the > real problem. For me it is a waste as it does not do as > most people expect. An OCR import would be a better option, > if we can find one. > I haven't looked at this in a while, but ... http://code.google.com/p/tesseract-ocr/ cheers, Pedro.
Re: OCR (was Re: A first try to remove some copyleft components from the build)
Pedro F. Giffuni wrote: > FWIW; > > --- On Mon, 7/18/11, Andy Brown wrote: > ... >> >> I agree with you that it is the expectations that cause the >> real problem. For me it is a waste as it does not do as >> most people expect. An OCR import would be a better option, >> if we can find one. >> > > I haven't looked at this in a while, but ... > > http://code.google.com/p/tesseract-ocr/ > > cheers, > > Pedro. > Thanks. It does look interesting from a quick glance. Bookmarked for reference. Andy
