Apache OpenOffice (AOO) Bugzilla – Issue 68817
Access to PACKAGEVERSION in the build environment
Last modified: 2007-03-29 13:29:53 UTC
It is useful to have access to the OO.o PACKAGEVERSION (from instsetoo_native/util/openoffice.lst) and its major, minor and micro version number components, in the build environment, for instance in Makefiles. As far as I could see there is no obvious way to do this except picking out the information from the openoffice.lst file. This could then as well be done already in config_office/configure.in and propagated through set_soenv instead of in individual makefile.mk files. Patch: --- config_office/configure.in +++ config_office/configure.in @@ -5189,6 +5189,17 @@ echo "* *" echo "********************************************************************" +AC_MSG_CHECKING([OpenOffice.org version]) +OOO_PACKAGEVERSION=`grep -m 1 PACKAGEVERSION ../instsetoo_native/util/openoffice.lst | sed -e 's/.*N *//' -e 's/ //g'` +AC_MSG_RESULT([$OOO_PACKAGEVERSION]) +AC_SUBST(OOO_PACKAGEVERSION) +OOO_PACKAGEVERSION_MAJOR=`echo $OOO_PACKAGEVERSION | cut -d. -f1` +OOO_PACKAGEVERSION_MINOR=`echo $OOO_PACKAGEVERSION | cut -d. -f2` +OOO_PACKAGEVERSION_MICRO=`echo $OOO_PACKAGEVERSION | cut -d. -f3` +AC_SUBST(OOO_PACKAGEVERSION_MAJOR) +AC_SUBST(OOO_PACKAGEVERSION_MINOR) +AC_SUBST(OOO_PACKAGEVERSION_MICRO) + if test -z "$COMPATH"; then AC_MSG_ERROR([No compiler found.]) fi dummy line to avoid confusing diff-mode --- config_office/set_soenv.in +++ config_office/set_soenv.in @@ -1510,6 +1510,10 @@ if ("@ENABLE_DEBUG@" eq "TRUE") { ToFile( "debug", "true", "e" ); } +ToFile( "OOO_PACKAGEVERSION","@OOO_PACKAGEVERSION@","e" ); +ToFile( "OOO_PACKAGEVERSION_MAJOR","@OOO_PACKAGEVERSION_MAJOR@","e" ); +ToFile( "OOO_PACKAGEVERSION_MINOR","@OOO_PACKAGEVERSION_MINOR@","e" ); +ToFile( "OOO_PACKAGEVERSION_MICRO","@OOO_PACKAGEVERSION_MICRO@","e" ); ToFile( "PRODUCT", "@PRODUCT@", "e" ); ToFile( "PROFULLSWITCH", "@PROFULLSWITCH@", "e" ); ToFile( "PROEXT", $PROEXT, "e" );
Sorry, but I do not really like the idea of module config_office grabbing around in foreign modules (allthough that would be less bad than some ordinary module or makefile doing so druing the build). If you need office's major, minor, and micro version number outside the packaging process, I could image two solutions: 1) Pull that information out of instsetoo_native/util/openoffice.lst, put it in some config file at f.e.solenv/config. Use it from there even for packaging. 2) Do not use these numbers explicitly but some variable which gets resolved by office application during runtime. OpenOffice.org knows its version from program/bootstraprc or program/versionrc. In any case please note that there is not just one value of PACKAGEVERSION per build. It's one value per product. For OOo we currently have (see openoffice.lst) OpenOffice, OpenOffice_wJRE, and OpenOffice_Dev (currently all with the same PACKAGEVERSION, but do not take that as guaranteed), and URE and OpenOffice_SDK. For Sun internal build you can imagine that we have additional products such as StarOffice, getting built in an internal module similar to instsetoo_native. (This could make solution (1) more difficult because there may be cases where Sun does not want to put versioning information for internal products on a public module.) Could you please give us some hint what you need that information for? You just wrote "It is useful". The best solution may well depend on the use case you have in mind.
> Could you please give us some hint what you need that information for? Sure, I didn't intend to keep it secret, just forgot to add more details... We want to have the product's version number in the version resources in the .DLL and .EXE files of the product, instead of the 8.x numbers that are there currently. I assume that the 8 comes from the version numbering of StarOffice, but that doesn't say much to customers who just know that they are using OpenOffice.org 2.x. (Isn't having those 8.x numbers in the Win32 binaries exactly an example of "putting versioning information for Sun internal products on a public module" that you say you want to avoid?)
> want to have the product's version number in the version resources in the .DLL > and .EXE files of the product, instead of the 8.x numbers that are there > currently. I assume that the 8 comes from the version numbering of StarOffice, > but that doesn't say much to customers who just know that they are using > OpenOffice.org 2.x. Huh, that's not easy. As I said, we have different version numbers for different product. F.e. a sal library (sal3.dll on windows) is part of OpenOffice.org (which currently is 2.0.4), OpenOffice_dev (the developer snapshot) and StarOffice (version 8 update 4). We use the same files for different products. So, what version number shall we take? It's easier for you doing OOo only, but nevertheless not a Sun only problem. As I said, it is not guaranted that all products delivered by OOo community have the same version number. Take office application and URE as an example, there may come more.
Hmm, yes, I see your point. When you say "same files", do you mean binary identical, or just same name? If you feel this is something that shouldn't go upstream, fine, I can resolve as WONTFIX then. We'll probably keep it as non-upstreamed patch for our builds. This discussion has been informative anyway, thanks.
I mean mean binary identical. Here in Hamburg RE we are building a workspace once and create install sets for StarOffice and OpenOffice.org from the same, identical set of binaries. OOo 2.0.3 built by us contains the same, binary identical libraries as SO8 update 3. I see your point, '8.x' is not correct as global versioning info. Unfortunately, I have no clue what a 'global version number', valid for all products, would be except a (somewhat meaningless for most users) build id.
As you proposed, I am setting this issue to WONTFIX and closed. Nevertheless I am not happy with the current situation. So, feel free to reopen if you have a good idea what a common, product independent version info could look like.
.
IIRC, it's is possible to link an "code only" application first and add resources in a second linker call. this could be the way to go for applications. for .dlls my favorite ist to drop the version completely and replace it with the corrosponding build id (see minor.mk in solenv/inc).
set issue to won't fix
close issue.