fdkaac icon indicating copy to clipboard operation
fdkaac copied to clipboard

Add VERSIONINFO resource

Open nkh0472 opened this issue 3 years ago • 6 comments

Display version info and file name under Windows.

Tested through latest Mingw-w64.

nkh0472 avatar Jun 11 '21 05:06 nkh0472

Thanks for the patch. I think it would be better if version number is automatically picked up from version.h. Is it possible?

nu774 avatar Jun 16 '21 12:06 nu774

I think it would be better if version number is automatically picked up from version.h.

Now the definition of the version number has been moved to version.h, and it has been tested through latest Mingw-w64.

As mentioned above, since the contents of those two variables in version.h are consistent, they can be further merged, ~~but I don't know how to do it.~~

const char *fdkaac_version = "1.0.2";
#define VER_VERSION_STR "1.0.2"

Update: char fdkaac_version has been replaced with VER_VERSION_STR in main.c. Test passed.

nkh0472 avatar Jun 16 '21 14:06 nkh0472

Did you try re-running autoreconf ? It now fails because configure.ac also picks up version information from version.h, and now it is different. The first lines of configure.ac has to be edited to something like this.

m4_define([VERSION_STR],m4_esyscmd([grep VER_VERSION_STR version.h]))
changequote({{,}})dnl
m4_define({{XX_VERSION}},m4_bregexp(VERSION_STR,{{.*VER_VERSION_STR "\(.+\).0".*}},{{\1}}))

Also, I'm skeptical of the last two commits which add explicit NUL at the end of the string. Are they really needed? Does that make difference on the generated file?

nu774 avatar Jun 17 '21 06:06 nu774

Did you try re-running autoreconf ? It now fails because configure.ac also picks up version information from version.h, and now it is different. The first lines of configure.ac has to be edited to something like this.

For the last four commit, I only tested make and the output of the complied fdkaac.exe. Thanks for your fix, now the whole process of compilation can run normally.

Also, I'm skeptical of the last two commits which add explicit NUL at the end of the string. Are they really needed? Does that make difference on the generated file?

I only saw such a sentence on a Chinese blog page today. Although the author did not give a reference, but in Microsoft's official example, all of the strings are written like this. So I think it's better to keep the writing consistent with the official documents.

Although there is no \0 as the end in this commit before, and the file properties can be displayed normally in my Windows 10; But I'm worried about whether this will cause compatibility or other problems on lower version systems or another compiler.

nkh0472 avatar Jun 17 '21 07:06 nkh0472

In C programming language, any string literal is terminated by a NUL, so you generally don't need them unless you need double NULs. If you are unsure, you should at least check if output of resource compiler (windres) is actually different or not. To begin with, don't push code if you are unsure. This is not your own repo.

nu774 avatar Jun 17 '21 08:06 nu774

If you are unsure, you should at least check if output of resource compiler (windres) is actually different or not.

They are the same. But I still think it's better to follow the example of the official document.

To begin with, don't push code if you are unsure. This is not your own repo.

I'm very sorry for the problem I caused. I will remember your advice.

nkh0472 avatar Jun 17 '21 08:06 nkh0472