Re: Platform ports vs. multiplatform
Hi Enrico, On Thu, 2012-11-15 at 20:57 +0100, Enrico Weigelt wrote: note that most of that can be handled by a proper file in ./distro-config/. yes, but at least according to debian/ubuntu build rules, that doenst seem to be enough. (debian's rule file is over 3k LOC) Ah - that does seem a tad unfortunate. I'm sure there are lots of good things in debian's rules file that we could fold into the core and make easier for distributors in an incremental fashion. Having not read the file - I've no concrete ideas there :-) but ... at least looking at how some of our .spec files re-order and re-group the scp2 break-down to get the packaging prettier lots could be improved in that bit alone. --disable-epm ? I'm talking about dropping it completely in my branch. By the way: what is this actually used for ? Not sure about the other distros, but Debian+friends dont seem to use it. Oh; EPM is used to build the generic cross-distribution packages that we ship for Linux. HTH, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Platform ports vs. multiplatform
Hi, yes, but at least according to debian/ubuntu build rules, that doenst seem to be enough. (debian's rule file is over 3k LOC) Ah - that does seem a tad unfortunate. I'm sure there are lots of good things in debian's rules file that we could fold into the core and make easier for distributors in an incremental fashion. Having not read the file - I've no concrete ideas there :-) but ... at least looking at how some of our .spec files re-order and re-group the scp2 break-down to get the packaging prettier lots could be improved in that bit alone. One thing we, IMHO, should do is splitting the whole thing into smaller parts, eg. building extensions or helpcontent out of tree, moving them to their completely own packages. That would make packager's life much easier. Another front is 3rdparty libraries. Optimally, as a packager, you want it to get its deps entirely from the system (or sysroot) - without having to tweak a lot of parameters - and _never_ let it download anything. Packaging then needs to run entirely through the distro's machinery. OTOH we've got platforms that don't know the concept of distros and package management/repositories. My approach to this is: having a separate 'workspace' system for handling all the things that usually distro build machines would do. Esentially rolling an own micro-distro (or multiple ones for several platforms). Such an micro-distro, eg. for win32/cygwin, would do things like: * proper toolchain setup, at least check if everything's correct, and guide the user through the setup (if it can't be done automatically) * deploy cygwin build environment and maybe pull in required packages * build missing dependencies (not yet in cygwin repos) and deploy them into the build environment * maybe provide some user friendly buildtime configuration (perhaps something windows-friendly counterpart of linux kernel's 'make menuconfig' ?) * build lo itself * create deployable packages (cygwin, msi, ...) install program (which maybe would just be a little wrapper around msi) Similarily, there could be such an 'workspace' for Debian+friends, which: * makes sure all required packages are installed (via apt-get calls) * builds the missing 3rdparty libs (that aren't in debian yet) into their own prefix (eg. /usr/lib/libreoffice/depend/), packaging to something like 'libreoffice-libraries', adding it to local aptrepo * drive the package build, w/ --with-system-*, adding proper pkg-config pathes and build proper deb packages * runs all package builds via pbuilder+friends --disable-epm ? I'm talking about dropping it completely in my branch. By the way: what is this actually used for ? Not sure about the other distros, but Debian+friends dont seem to use it. Oh; EPM is used to build the generic cross-distribution packages that we ship for Linux. Well, to have it really generic, you'll need to link statically against all libraries normally found on operating systems, down to libc. This leads to an huge increase in diskspace and memory consumption. Another drawback is that bugfixes (esp. security-related!) coming from their distro. I'd consider that as a workaround if you _really_ need very recent versions that aren't distro-packaged yet. At this point, I'd seriously raise the question why distros lag behind so far that people get interested in such an cross-dist package. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Platform ports vs. multiplatform
Hi folks, I'm currently working on an downstream fork (means: regularily rebased) for an GNU/Linux-only version. The idea is: make it trivial to build/install on common GNU/Linux distros, so no additional magic is required for packaging. Major points: * drop all bundled libraries that are already available on mainline distros * simplify the import logic (eg. use pkg-config whereever possible) * drop all specific logic for other platforms * drop EPM stuff Once that's working, I'd like to extend it to other platforms (eg. win32). Yet to be explored: can/should cygwin,ming32,android be treated as GNU favours or be separated platforms. If anyone's interested in this, just let me know. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Platform ports vs. multiplatform
On Thu, Nov 15, 2012 at 5:14 AM, Enrico Weigelt enrico.weig...@vnc.biz wrote: * drop all bundled libraries that are already available on mainline distros note that most of that can be handled by a proper file in ./distro-config/. * simplify the import logic (eg. use pkg-config whereever possible) * drop all specific logic for other platforms what is the benefit of that, except creating busy work for you ? * drop EPM stuff --disable-epm ? Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Platform ports vs. multiplatform
Hi, * drop all bundled libraries that are already available on mainline distros note that most of that can be handled by a proper file in ./distro-config/. yes, but at least according to debian/ubuntu build rules, that doenst seem to be enough. (debian's rule file is over 3k LOC) * simplify the import logic (eg. use pkg-config whereever possible) * drop all specific logic for other platforms what is the benefit of that, except creating busy work for you ? For now, at least some hacking fun, learning a bit more about the lo internals and maybe in the end a much simpler build system. The whole operation gets more intersting when done for multiple platforms. I'll start w/ win32 once i'm done w/ gnu/linux. * drop EPM stuff --disable-epm ? I'm talking about dropping it completely in my branch. By the way: what is this actually used for ? Not sure about the other distros, but Debian+friends dont seem to use it. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
