mtconleyuk
10th June 2009 15:54 UTC

VIProductVersion not performing define substitution?
Just updated to 2.45, and now VIProductVersion, which in previous builds was converting defines to numbers for me, is no longer working, and complains about the format (requiring X.X.X.X).

I have code that basically does the following:

!searchparse /noerrors /file "version.rc" "#define kReleaseVersion" PRODUCT_VERSION_MAJOR "," PRODUCT_VERSION_MINOR "," PRODUCT_VERSION_SUBRELEASE

!define PRODUCT_VERSION "${PRODUCT_VERSION_MAJOR}.${PRODUCT_VERSION_MINOR}.${PRODUCT_VERSION_SUBRELEASE}"

!define INSTALLER_RELEASE "0"
!define INSTALLER_PRODUCT_VERSION "${PRODUCT_VERSION}.${INSTALLER_RELEASE}"

...

VIProductVersion "${INSTALLER_PRODUCT_VERSION}"

This used to work fine, and no longer does. Bug?

mtconleyuk
10th June 2009 16:13 UTC

Actually, glancing at the release notes, I see the following ominous note:

Fixed !searchparse (bug #2680110)

Since I rely on !searchparse to perform the above operation, and since now, even if I subsitute literals for the !define values to VIProductVersion, I get errors complaining that the !defines are no longer defined, I'm beginning to suspect that !searchparse isn't doing what it's supposed to anymore.

Animaether
10th June 2009 16:15 UTC

should still work. why not use "!echo ${INSTALLER_PRODUCT_VERSION}" to check what the value ends up as?

mtconleyuk
10th June 2009 16:23 UTC

If I remove the /noerrors flag, I get a 'string not found in file' error. This is patently false, since the string does exist in the file.

Upon closer observation, I note that there is now a new bug filed, 2803622, 'SearchParse regression in 2.45', which describes exactly this problem. So I'm not the only one, it appears.

Afrow UK
10th June 2009 16:27 UTC

Works fine for me when the file just contains #define kReleaseVersion 1,0,0

Stu

mtconleyuk
10th June 2009 16:35 UTC

Okay, now put a blank line in front of it, like this:

#define kCMWinReleaseVersion 2,2,2
#define kCMWinReleaseCode 101
#define kCMWinBuildNumber 416

Afrow UK
10th June 2009 16:45 UTC

Is that from the file you are using? If so then it's got kCMWinReleaseVersion and not kReleaseVersion in it.

But otherwise if I do put some blank lines in front of it it has no effect.

Stu

mtconleyuk
10th June 2009 16:55 UTC

Yes, sorry, forgot to cleanse the names. But they're what I'm using.

I've enclosed a zipped copy of a test script and the data file. Try compiling SearchParseTest.nsi; does it work?

Afrow UK
10th June 2009 17:14 UTC

The problem is that the file is using only line feeds for new lines as opposed to carriage returns + line feeds. Interesting that this breaks !searchparse

Stu

mtconleyuk
10th June 2009 17:19 UTC

Yup. That's it exactly. Thought I had checked for that, but I guess not.

In any case, !searchparse used to be able to handle it, but no longer does, apparently.

mtconleyuk
10th June 2009 17:27 UTC

Hm. May have spoken too soon. I just tried the test file again, having ensured that all my line breaks are CRLF, and it doesn't work. I've enclosed a new copy of the test script and file, zipped. Does this work for you, or not?

Afrow UK
10th June 2009 20:11 UTC

Yeh definitely a new bug. It looks like it stops searching when it finds an empty line. As you said if you don't have the blank line or if you just put in some spaces or tabs then it works fine.

Please file a bug report on the tracker:
http://sourceforge.net/tracker/?grou...49&atid=373085

Stu

mtconleyuk
11th June 2009 07:58 UTC

Shouldn't I just add to the one already filed (2680110)?

mtconleyuk
11th June 2009 08:14 UTC

Sorry, I meant 2803622, and it looks like that one's been closed as fixed. So hopefully this goes away in the next release.