is -> ericb:
instsetoo_native/util/openoffice.lst is exactly what you are looking for. This
is the file, in which you can define products. Many properties can be set in
this file, like ProductName, ProductVersion, ...
This file is the central start point for the packager, when a special product
with a special language has to be created. Some variables like ProductName and
ProductVersion are also written into the configuration files, so that they are
also available to the installed Office product during runtime. 
No other place is allowed than instsetoo_native/util/openoffice.lst .
Unfortunately we need currently the hack, that the version also needs to be set
in sysui. But this is caused by the problem, that packages are created in sysui.
The correct way would be, to define the packages in scp2 and let the packager
create them. But this was not introduced because of time pressure. 
For the Mac OS files, we should introduce a mechanism, that the ProductVersion
is written into this files (if this is really required) during the packaging
process. Perhaps you can use the mechanism, that we use for example for the
setup.xcu, where the content

		<prop oor:name="ooName">
			<value>${PRODUCTNAME}</value>
		</prop>
		<prop oor:name="ooSetupVersion">
			<value>${PRODUCTVERSION}</value>
		</prop>
		<prop oor:name="ooSetupExtension">
			<value>${PRODUCTEXTENSION}</value>
		</prop>
		<prop oor:name="ooXMLFileFormatVersion">
			<value>${FILEFORMATVERSION}</value>
		</prop>
		<prop oor:name="ooXMLFileFormatName">
			<value>${FILEFORMATNAME}</value>
		</prop>
		<prop oor:name="ooOpenSourceContext">
			<value>${OPENSOURCE}</value>
		</prop>

is replaced during packaging process to

		<prop oor:name="ooName">
			<value>OpenOffice.org</value>
		</prop>
		<prop oor:name="ooSetupVersion">
			<value>2.1</value>
		</prop>
		<prop oor:name="ooSetupExtension">
			<value></value>
		</prop>
		<prop oor:name="ooXMLFileFormatVersion">
			<value>1.0</value>
		</prop>
		<prop oor:name="ooXMLFileFormatName">
			<value>OpenOffice.org</value>
		</prop>
		<prop oor:name="ooOpenSourceContext">
			<value>1</value>
		</prop>

In scp you have to set the flag SCPZIP_REPLACE

File gid_File_Oo_Setup_Xcu
    TXT_FILE_BODY;
    Styles = (PACKED, SCPZIP_REPLACE,PATCH);
    Dir = gid_Dir_Share_Registry_Data_Org_Openoffice;
    Name = "/registry/data/org/openoffice/Setup.xcu";
End

This is even implemented for binary files like the soffice.exe. If you want to
patch such a file, you have to set in scp2 the flag PATCH_SO_NAME, to include
the ProductName.

So in my opinion there is nothing to do, because this central place already
exists and different processes are available to use the packaging process to
include this properties into different files.

cc'ing myself.

Eric:

here's an example script that could be used for our Mac OS X stuff. It is
possible to extend this to cover the possible variations too: 2 or 2.1 or 2.1.0

It not the most elegant solution, but it works :)

#!/bin/sh
#
# desktop/macosx/source/getooover.sh
#
# get the current OpenOffice version number

grep PRODUCTVERSION ../../../instsetoo_native/util/openoffice.lst | grep -i -v
USER | head -1 | sed -e 's/.*PRODUCTVERSION //g' | sed -e 's/ //g'

ericb->is

Thank you for your long answer, but I fear this is not what we expect. I'll try to describe better what we 
need, and if I'm wrong, please point what I miss.  Thanks in advance :-)

First, product version (and some other) infos are mandatory  _at_buildtime_ , because we create a 
bundle. scp2 won't help here, but I can be wrong.

About productversion.mk in sysui:  this is not a correct statement, and at least variables don't have to 
be in this module : one file containing these infos in solenv, is a more correct solution :

Imagine distributed build context : all modules can see solenv, not sysui content, whorse, other 
modules who need productversion : same issue.

Note :if several modules need the same info, this is a design problem, and again a global solution must 
be found.


ericb->mox

Thanks for your script, but this is my fault, I didn't present things completely :
I asked for a central point, in distributed build context.

Imagine other modules are not on the same level, for example sysui and desktop are not on the same 
machine : access sysui infos from desktop module becomes suddenly less easy/simple.

That's one of the reasons why I limited my suggestions to solenv and the solver.

The other one is unnecessary duplicated informations : maintainability is harder .. etc

Last but not least, if none disagrees, your script is ok for me.

is -> ericb:  The basic idea in the build process is, that all cvs modules, that
are built before instsetoo_native, do not need any information about
productname, productversion, productextension, default destination directory and
so on, and so on. And nearly all modules are built before instsetoo_native,
which creates the installation sets. Therefore everything built before
instsetoo_native can be used for any product with any version. Only
instsetoo_native knows, which product in which version in which language and
with which package format shall be created (except sysui, what is of course a
big error, that was introduced because of time pressure).
If there are files, that have to include the packagename or the packageversion,
this info has to be written into this files during packaging process in
instsetoo_native, not earlier. If this does not work for your files now, we have
to introduce a new process for this in the packaging process. During build time
of your cvs module, you have to use a placeholder, that is replaced in packaging
process.
Therefore I explained scp2, where are flags for files available, that are
evaluated during packaging time. For example the binary "soffice.exe" is
modified during packaging process, because it has to contain the productname.
setup.xcu is modified, because it has to know productname, productversion and
much more information. 
mox script is of course  a fix, because it uses the info from openoffice.lst,
but this is exactly what was not intended in our build process. Please introduce
a placeholder in your cvs module ( ${PRODUCTVERSION}  ), that is replaced in
packaging process (for binary files we will probably have to expand the existing
process).


  

ericb->is

Ok, I have -at least- understood, and I agree with you. This means what we introduced in desktop is 
wrong :-/  

.. and we have to move (to be verified) all the desktop/macosx stuff into instsetoo_native

Pavel, Oliver, what do you think about that ?

eric: The way "is" has described the build process, it seems that we, indeed,
would have to move most of the stuff in desktop/macosx to instsetoo_native.

This may not be such a bad idea anyways, because the further pkg install work
would benefit from this.

ericb->mox

I'm ok for the change, i.e. move desktop/macosx somewhere in instsetoo_native, and to use .pkg 

FYI, I know Oliver has something in mind for that, but I think we should discuss more on mac@porting 
and/or on #ooo_macport before to start. ( like how help Oliver, for example).

ericb->is 

Thank you very much for your time and your explanations. We will follow them.
Once other are ok, this issue will probably be reopen

Another option is to extend the binary patching algorith Ingo mentioned to meet our needs (currently it 
does not support a product version).

Created attachment 41719 [details]
Some code changes are needed to accommondate the move of some mac os x desktop stuff to instsetoo_native

is: please assign this issue to ericb. As per ericb's decision, we will continue
to use this issue to fix the Mac OS X versioning problems.

ericb/others: The patch I posted fixes the files in desktop and
instsetoo_native, when the Info* and *.applescript files are moved.

In addition to the patch, you will have to do the following things:

1) rm desktop/macosx/source/misc/makefile.mk
2) mkdir -p instsetoo_native/macosx
3) mv desktop/macosx/source/Info* instsetoo_native/macosx/
4) mv desktop/macosx/source/*.applescript instsetoo_native/macosx/
5) apply the patch

Created attachment 41722 [details]
Fixes versioning problems with Mac OS X specific files

The second patch builds on the first patch and makes the versioning of Mac OS X
-specific files completely automatic.

I would have filed that patch to issue 71818, but Ericb used it for quickfixing
OOo 2.2.

I have slightly changed the places of files, so instead of having *.applescript
and Info* in instsetoo_native/macosx/, they should be put to
instsetoo_native/macosx/application/

The reason for this is that I'm working with pkg installer, and that probably
will have similarly named files in instsetoo_native/macosx/installer/

So these are the new steps for the first+second patch:
2) mkdir -p instsetoo_native/macosx/application
3) mv desktop/macosx/source/Info* instsetoo_native/macosx/application/
4) mv desktop/macosx/source/*.applescript instsetoo_native/macosx/application/

Slightly modified versions of these patches have been committed to
cws macosxversioning01. Further work will be done in the cws to make it
integrated with the build process.

Well, I did not say, that you should shift your code from desktop to
instsetoo_native. But of course this is a solution. 
I would prefer, that you leave the code in desktop, but write it in a manner,
that it does not need any info about productname, productversion, ... . The most
flexible solution would be to use placeholder in your code, that are replaced
during packaging process. For example the string "OpenOffice.org" is written
into the binary file soffice.exe during packaging, too. Such a binary
replacement mechanism probably has to be expanded. 

is -> ericb: Sending back to you, because a patch is available.

Updated patch has been filed into cws macosxversioning01

Ericb: can you change the Resolution to Fixed (or assign the issue to me)

There's lot's of future work that depend on versioning stuff to be in
instsetoo_native.

Using binary patching is not desirable if a simpler source-code based replacing
can be done. It is way more reliable (to verify correct changes),
easier-to-change, and easier-to-add new functionality.

Of course, all stuff that still can be in desktop will be kept/put there, only
the absolutely necessary files are in instsetoo_native. Currently means just 4
text files in instsetoo_native (that used to be in desktop).

The future work will (at least) be in areas of 1) separate .apps (Writer.app,
Calc.app etc), 2) .pkg installer 3) Spotlight plugin installer

Following pjanik's recommendations, filed the patch-related work as issue 73223. 

So this issue is resolved and stays as WORKSFORME.

please, check if the conflicts in desktop/macosx/source/makefile.mk (between
-r1.7 and -r1.5.138.1) are correctly solved in r1.8

vg: yes the merge (makefile.mk, 1.8) has been done correctly. Thank you for the
work.

The Issue you raised has been marked as 'Resolved' and not updated within the
last 1 year+. I am therefore setting this issue to 'Verified' as the first step
towards Closing it. If you feel this is incorrect, please re-open the issue and
add any comments.

Many thanks,
Andrew
 
Cleaning-up and Closing old Issues
~ The Grand Bug Squash, pre v3 ~
http://marketing.openoffice.org/3.0/announcementbeta.html

As per previous posting: Verified -> Closed.
A Closed Issue is a Happy Issue (TM).

Regards,
Andrew