Thanks for comments :)
On 31-03-2010 15:15, Adrian Buehlmann wrote:
> On 31.03.2010 13:28, Sune Foldager wrote:
>> +
>> + def repoversion(verfile):
>> + globals = {}
>> + execfile(verfile, globals)
>> + return globals.get('version', 'unknown')
>> +
>> + hgversion = repoversion('../build-hg/mercurial/__version__.py')
>> +
>> extra['console'] = [
>> {'script':'../build-hg/hg',
>
> Not sure about using '../build-hg/hg' here (your patch 1). I'll leave
> this to Steve to decide.
No, it's not optimal, I know. On the other hand, it's not optimal to
have (sometimes out of date) copies of Mercurial files in thg repo just
to do builds... so I guess it's a trade-off. These patches were meant as
RFCs to begin with, btw.
>> 'icon_resources':[(0,'icons/hg.ico')],
>> 'description':'Mercurial Distributed SCM',
>> 'copyright':hgcopyright,
>> - 'product_version':version},
>> + 'product_version':hgversion},
>> {'script':'hgtk',
>> 'icon_resources':[(0,'icons/thg_logo.ico')],
>> 'description':'TortoiseHg GUI tools for Mercurial SCM',
>
> Hmmmmm.
>
> With this patch 2, the version resource binary file version of the exe
> will still be the "binary" Windows version of TortoiseHg then (the
> binary version is a tuple of four non-negative integers).
Yes.
> File version: 1.0.1134.0
> Product: TortoiseHg
> Product version: 1.5+62-1b4568d3deb
>
> Windows installer doesn't look at the product version string
> ("1.5+62-1b4568d3deb") when deciding to exchange a files (in minor
> upgrades). It only looks at the first three numbers of the binary file
> version ("1.0.1134.0").
Right... so this is just to make the 'product version' if someone
decides to do a 'version info' on the file, correct. Otherwise there is
no need to set the product version at all. The file version gets set
either way.
> (Which -- as a side note -- is one of the reasons why minor upgrades --
> in Windows installer terms -- can't work with our current sources: we
> don't reliably count up one of the first three numbers there.)
Right. The situation is even worse for repoman where I package repoman +
tortoisehg + mercurial. I don't have enough version number elements to
ensure anything, so I didn't bother putting the mercurial periodic as
fourth element, like thg does :).
> So, if you are aiming at enabling minor upgrades, I guess you'd probably
> rather want (hypothetical example):
>
> File version: 1.5.1062.0
> Product: TortoiseHg
> Product version: 1.0+134-abb41e99f72b
> for that hg.exe.
Yes, but I wasn't trying that this time around :-). I just wanted the
'product version' to be correct, so that value wasn't "lost" (except for
hg version, hgtk version). The value is completely informal anyway.
Second patch has the same "problem" as the first, of course, in that it
relies on the winbuild environment.
Another way we might do it is not use thg's setup at all, and have one
in winbuild instead. This is what I currently do for repoman. But this,
of course, also has its own downsides.
The fact is that thg-winbuild IS very tightly coupled with both
mercurial and tortoisehg on the WIX front already. If we still want
people to be able to 'py2exe' tortoisehg without a winbuild environment,
we can put in some if's in the setup to make this optional :).
/Sune
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Tortoisehg-develop mailing list
Tortoisehg-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
