autogenerated files in release tarball

[fossfreedom]

Ikey,
comment from Gianfranco the reviewer of the 10.2.7 package for Debian

"I see a lot of autogenerated files:

"/* main.c generated by valac 0.32.1, the Vala compiler"

are you sure you are rebuilding them in Debian builds?

grep generated . -Ri |grep vala |grep -v "do not" |wc -l
57"

I take it this is expected and the .c files Gianfranco is referring to in the release tarball are either being rebuilt from .vala and/or just being used in the build as is?

David

[ikeydoherty]

I seem to remember we had this conversation before, getting deja vu anyway :) That's how the Vala+autotools stuff works. The only way for me to workaround it is to forcibly delete the stamps, which in turn breaks distcheck. We don't use any conditionals in the Vala code for exactly this reason, we know the .c files aren't being regenerated, so the conditionals would never work (they don't make it to the .c..)

We could try to hack the .c's out it, but I think the time would be best spent on rewriting to C for 10.3, as we need to fix all those odd issues (like not being able to have proper relro plugins), then we can just drop all the .vala anyway. I'd like to see what Debian makes of that proposition, because I think we're all a bit sick of Vala in Budgie Desktop by now anyway, right? :)

[LocutusOfBorg]

Hi, an alternative approach might be to delete them at the begin of the Debian build
(dh_clean probably), so they are auto-generated, if I understand correctly the discussion.
Is it an acceptable/working approach?
this would mean "don't touch the upstream code/source" :)

the need to regenerate them is usually a good thing, because in case a bug is spot in vala, a no change rebuild will fix all the vala dependencies.

[ikeydoherty]

One that in theory works, is running "make maintainer-clean" after configuring, and then re-autogenning. Should blitz the files

[ikeydoherty]

Fixed by move to meson