Apache OpenOffice (AOO) Bugzilla – Issue 57132
Stand-alone UNO (URE) available in binary format only
Last modified: 2017-09-09 10:51:59 UTC
What is the point of making binary-only releases of LGPL software? URE-1.0.1 _binaries_ are currently available (in a rather awkward format, I might add) for only a few platforms. Can the .tar.bz2, please, be made available too (as LGPL would imply)? Then, the libraries can be ported and *tested* independently on a new platform. Please, be sure to NOT package the STLport sources inside. STLport is a third party software and is already ported to more platforms than OOo. This applies to other 3rd-party packages (expat, sablotron, etc.), which are currently shipped inside OOo's giant distributions. Thank you!
@sb: we should provide some information on how to build the URE bits and include them into the readme.
The URE product (like other products: OOo itself, SDK) is currently built as part of building the complete OOo code base. Granted, this is not ideal, and will most probably change in the future. For reasons of UNO compatibility, we are stuck with the STLport version included in the OOo code base for URE and OOo itself, at least for those platforms where we care about the UNO compatibility guarantees. I am not sure whether you object against requiring a specific STLport version for building OOo, or against physically including the source of that specific version in the OOo code base. Assuming the former, there are two points to this: (1) If you want to create a private version of URE or OOo itself that is not guaranteed UNO-compatible with the rest of the world, you can try to build with some other STL than the STLport version included in the OOo code base---there is some configure switch, but I do not know how well it works. (2) If you are porting URE (and maybe OOo itself) to some new platform, you can think of generally using some other STL than the STLport version included in the OOo code base on that platform (in which case you should still take care of any compatibility issues that may imply). I can of course add something along the lines of "to build URE, you currently need to build OOo" to the URE readme for OOo 2.0.2; when the URE gets buildable more easily, I will then update the URE readme accordingly.
I'd like to be able to build URE with (or without) the STLport of my choosing. I do not care for "compatibility", because there are no products to be compatible with on FreeBSD -- especially, on non-i386 FreeBSD. Am I right, that there can be no _cross-platform_ "UNO-compatibility with rest of the world" anyway? ="to build URE, you currently need to build OOo" Is not it supposed to be the opposite?
Re: Am I right, that there can be no _cross-platform_ "UNO-compatibility with rest of the world" anyway? Yes, the issue is binary compatibility at the level of the sal/salhelper/cppu/cppuhelper library ABIs. Re: Is not it supposed to be the opposite? Yes, but as long as nobody actually does the necessary changes, it will stay this way.
sb wrote: "I can of course add something along the lines of "to build URE, you currently need to build OOo" to the URE readme for OOo 2.0.2" Is there indeed demand for that? Thinking about it, I think no, there is no need to mention it in the README. Hence, I will keep this issue open and retargeted to OOo Later, until URE is indeed buildable independent of the rest of OOo.
The sooner you do this, the better. Building the entire OOo is quite a daunting task right now even with the fastest processors and harddrives. Being able to work with sub-components independently would speed up development and provide for finer-grain unit testing.
@panbk: see <http://installation.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=1063> and follow ups for some activity in this area
Reset assigne to the default "issues@openoffice.apache.org".