Errors building 0.8.0 against Vala 0.25

[brouhaha]

I maintain (theoretically) the valabind package for Fedora. Up through Fedora 20, we have valabind 0.7.4 and vala 0.22. Fedora 21 and rawhide now use vala 0.25, and the valabind build breaks. I updated to valabind 0.8.0, but that still doesn't seem to build with vala 0.25. I get these errors:

Compiling config.vala main.vala valabindwriter.vala nodeffiwriter.vala utils.vala girwriter.vala swigwriter.vala cxxwriter.vala ctypeswriter.vala dlangwriter.vala -> valabind
valac -g --cc="cc" -X -O2 -X -g -X -pipe -X -Wall -X -Werror=format-security -X -Wp,-D_FORTIFY_SOURCE=2 -X -fexceptions -X -fstack-protector-strong -X --param=ssp-buffer-size=4 -X -grecord-gcc-switches -X -m64 -X -mtune=generic -X -Wl,-z,relro -o valabind --pkg posix --pkg libvala-0.26 --save-temps  config.vala main.vala valabindwriter.vala nodeffiwriter.vala utils.vala girwriter.vala swigwriter.vala cxxwriter.vala ctypeswriter.vala dlangwriter.vala 
swigwriter.vala:88.34-88.45: error: Argument 1: Cannot convert from `Vala.Expression?' to `int'
            return element+"[%d]".printf (array.length); // FIXME will this work?
                                          ^^^^^^^^^^^^
swigwriter.vala:262.52-262.63: error: Argument 1: Cannot convert from `Vala.Expression?' to `int'
            field = element + " " + f.name + "[%d]".printf (array.length); // FIXME will this work?
                                                            ^^^^^^^^^^^^
nodeffiwriter.vala:70.46-70.57: error: Argument 1: Cannot convert from `Vala.Expression?' to `int'
            return "_.array("+element+", %d)".printf (array.length);
                                                      ^^^^^^^^^^^^
ctypeswriter.vala:209.41-209.52: error: Argument 1: Cannot convert from `Vala.Expression?' to `int'
            return "'"+element+"', * %d".printf (array.length); // FIXME will this work?
                                                 ^^^^^^^^^^^^
ctypeswriter.vala:411.53-411.64: error: Argument 3: Cannot convert from `Vala.Expression?' to `int'
            field = "'%s', %s * %d".printf (f.name, element, array.length);
                                                             ^^^^^^^^^^^^
dlangwriter.vala:184.10-184.26: error: Assignment: Cannot convert from `Vala.Expression?' to `int'
                    int sz = array.length;
                        ^^^^^^^^^^^^^^^^^
dlangwriter.vala:185.51-185.52: error: The name `sz' does not exist in the context of `DlangWriter.walk_field'
                    defs += "  %s %s[%d];\n".printf (type, name, sz);
                                                                 ^^
Compilation failed: 7 error(s), 0 warning(s)

Adding explicit casts of array.length to int seems to work (or at least keep the compiler from complaining), but I have no clue what to do about sz.

[radare]

There is a branch from a debian guy who did 8 patches and reported none to me. I still have to review them and check which are the changes on the latest vala compiler api. Can you confirm your patch works and makes the r2 bindings compile properly?

Thanks

On 15 Aug 2014, at 08:36, Eric Smith notifications@github.com wrote:

I maintain (theoretically) the valabind package for Fedora. Up through Fedora 20, we have valabind 0.7.4 and vala 0.22. Fedora 21 and rawhide now use vala 0.25, and the valabind build breaks. I updated to valabind 0.8.0, but that still doesn't seem to build with vala 0.25. I get these errors:

Compiling config.vala main.vala valabindwriter.vala nodeffiwriter.vala utils.vala girwriter.vala swigwriter.vala cxxwriter.vala ctypeswriter.vala dlangwriter.vala -> valabind valac -g --cc="cc" -X -O2 -X -g -X -pipe -X -Wall -X -Werror=format-security -X -Wp,-D_FORTIFYSOURCE=2 -X -fexceptions -X -fstack-protector-strong -X --param=ssp-buffer-size=4 -X -grecord-gcc-switches -X -m64 -X -mtune=generic -X -Wl,-z,relro -o valabind --pkg posix --pkg libvala-0.26 --save-temps config.vala main.vala valabindwriter.vala nodeffiwriter.vala utils.vala girwriter.vala swigwriter.vala cxxwriter.vala ctypeswriter.vala dlangwriter.vala swigwriter.vala:88.34-88.45: error: Argument 1: Cannot convert from Vala.Expression?' toint' return element+"[%d]".printf (array.length); // FIXME will this work? ^^^^^^^^^^^^ swigwriter.vala:262.52-262.63: error: Argument 1: Cannot convert from Vala.Expression?' toint' field = element + " " + f.name + "[%d]".printf (array.length); // FIXME will this work? ^^^^^^^^^^^^ nodeffiwriter.vala:70.46-70.57: error: Argument 1: Cannot convert from Vala.Expression?' toint' return ".array("+element+", %d)".printf (array.length); ^^^^^^^^^^^^ ctypeswriter.vala:209.41-209.52: error: Argument 1: Cannot convert from Vala.Expression?' toint' return "'"+element+"', * %d".printf (array.length); // FIXME will this work? ^^^^^^^^^^^^ ctypeswriter.vala:411.53-411.64: error: Argument 3: Cannot convert from Vala.Expression?' toint' field = "'%s', %s * %d".printf (f.name, element, array.length); ^^^^^^^^^^^^ dlangwriter.vala:184.10-184.26: error: Assignment: Cannot convert from Vala.Expression?' toint' int sz = array.length; ^^^^^^^^^^^^^^^^^ dlangwriter.vala:185.51-185.52: error: The name sz' does not exist in the context ofDlangWriter.walk_field' defs += " %s %s[%d];\n".printf (type, name, sz); ^^ Compilation failed: 7 error(s), 0 warning(s) Adding explicit casts of array.length to int seems to work (or at least keep the compiler from complaining), but I have no clue what to do about sz.

— Reply to this email directly or view it on GitHub.

[radare]

Can you check if this is fixed in the debian fork? git://anonscm.debian.org/pkg-vala/valabind.git

On 15 Aug 2014, at 08:36, Eric Smith notifications@github.com wrote:

I maintain (theoretically) the valabind package for Fedora. Up through Fedora 20, we have valabind 0.7.4 and vala 0.22. Fedora 21 and rawhide now use vala 0.25, and the valabind build breaks. I updated to valabind 0.8.0, but that still doesn't seem to build with vala 0.25. I get these errors:

Compiling config.vala main.vala valabindwriter.vala nodeffiwriter.vala utils.vala girwriter.vala swigwriter.vala cxxwriter.vala ctypeswriter.vala dlangwriter.vala -> valabind valac -g --cc="cc" -X -O2 -X -g -X -pipe -X -Wall -X -Werror=format-security -X -Wp,-D_FORTIFYSOURCE=2 -X -fexceptions -X -fstack-protector-strong -X --param=ssp-buffer-size=4 -X -grecord-gcc-switches -X -m64 -X -mtune=generic -X -Wl,-z,relro -o valabind --pkg posix --pkg libvala-0.26 --save-temps config.vala main.vala valabindwriter.vala nodeffiwriter.vala utils.vala girwriter.vala swigwriter.vala cxxwriter.vala ctypeswriter.vala dlangwriter.vala swigwriter.vala:88.34-88.45: error: Argument 1: Cannot convert from Vala.Expression?' toint' return element+"[%d]".printf (array.length); // FIXME will this work? ^^^^^^^^^^^^ swigwriter.vala:262.52-262.63: error: Argument 1: Cannot convert from Vala.Expression?' toint' field = element + " " + f.name + "[%d]".printf (array.length); // FIXME will this work? ^^^^^^^^^^^^ nodeffiwriter.vala:70.46-70.57: error: Argument 1: Cannot convert from Vala.Expression?' toint' return ".array("+element+", %d)".printf (array.length); ^^^^^^^^^^^^ ctypeswriter.vala:209.41-209.52: error: Argument 1: Cannot convert from Vala.Expression?' toint' return "'"+element+"', * %d".printf (array.length); // FIXME will this work? ^^^^^^^^^^^^ ctypeswriter.vala:411.53-411.64: error: Argument 3: Cannot convert from Vala.Expression?' toint' field = "'%s', %s * %d".printf (f.name, element, array.length); ^^^^^^^^^^^^ dlangwriter.vala:184.10-184.26: error: Assignment: Cannot convert from Vala.Expression?' toint' int sz = array.length; ^^^^^^^^^^^^^^^^^ dlangwriter.vala:185.51-185.52: error: The name sz' does not exist in the context ofDlangWriter.walk_field' defs += " %s %s[%d];\n".printf (type, name, sz); ^^ Compilation failed: 7 error(s), 0 warning(s) Adding explicit casts of array.length to int seems to work (or at least keep the compiler from complaining), but I have no clue what to do about sz.

— Reply to this email directly or view it on GitHub.

[ritzk]

I have one here - https://github.com/ritzk/valabind

[radare]

Your patch segfaults in vala 0.23 and you are changing the license and authoring of a file you didnt created

On 16 Aug 2014, at 12:15, Ritesh Khadgaray notifications@github.com wrote:

I have one here - https://github.com/ritzk/valabind

— Reply to this email directly or view it on GitHub.

[radare]

Confirmed. The debian patch is generating wrong swig files. This is why the debian package cant compile the python swig bindings of r2.

So neither debian or ritesh patches are fine.

On 16 Aug 2014, at 12:15, Ritesh Khadgaray notifications@github.com wrote:

I have one here - https://github.com/ritzk/valabind

— Reply to this email directly or view it on GitHub.

[radare]

I have merged your change and added an #if check to ensure its being used with vala >= 0.25 , i have done some tests and it seems to work fine.

[brouhaha]

I pulled the latest code from Git and it still fails to compile for me. The conditional in the line:

if VALA_0_25

apparently is being evaluated as false, even though I'm using Vala 0.25. How is this variable supposed to get set?

I could edit the generated Makefile to add a -DVALA_0_25 to VALAFLAGS, but that doesn't seem like a good solution.

[brouhaha]

Assuming that the code intended for Vala 0.25 won't work on earlier versions, and that Vala 0.25 and later will gradually displace the earlier versions, would it make sense to have the code use the approach needed for Vala 0.25 and catch whatever error results on earlier versions and handle in the old way?

[radare]

This define is setted by valac. You can check the source. It will set all VALA version variables up to the valac version. So next releases of vala will also contain that define.

I think this must be a compile condition instead of a runtime one because it requires that change at compile time (new code doesnt builds with old usage).

We should investigate why your vala doesnt sets that variable. Multiple installs?

On 26 Aug 2014, at 02:22, Eric Smith notifications@github.com wrote:

Assuming that the code intended for Vala 0.25 won't work on earlier versions, and that Vala 0.25 and later will gradually displace the earlier versions, would it make sense to have the code use the approach needed for Vala 0.25 and catch whatever error results on earlier versions and handle in the old way?

— Reply to this email directly or view it on GitHub.

[radare]

The current code works for all versions i tried

On 26 Aug 2014, at 02:22, Eric Smith notifications@github.com wrote:

Assuming that the code intended for Vala 0.25 won't work on earlier versions, and that Vala 0.25 and later will gradually displace the earlier versions, would it make sense to have the code use the approach needed for Vala 0.25 and catch whatever error results on earlier versions and handle in the old way?

— Reply to this email directly or view it on GitHub.

[brouhaha]

I'm stumped. I build it using the Fedora Koji build system, which installs a fresh Fedora system in a chroot sandbox for the build, and from the log I can see that it's definitely installing Vala 0.25. It's possible that the build host has a different Vala installed outside the sandbox, but that shouldn't be accessible. I'll experiment more to try to track it down in the build system. I'll install a Fedora 21 daily build in a virtual machine and see if it builds correctly locally (without Koji/mock).

Thanks!

[kalev]

It should probably be:

if VALA_0_26

Vala 0.25.x are development releases leading up to the stable 0.26 release and the API version in the 0.25 releases is already set to 0.26 to avoid a version bump when the stable release comes out.