webhelper: remove generated files from version control

[techee]

These two get always regenerated on build on my machine with changes in the comments and are marked as modified by git, which is annoying.

Unless I miss anything, as they are regenerated, they don't have to be tracked by VCS.

[codebrainz]

I have them in .git/info/exclude here :)

[frlan]

At least it's compiling with waf and autotools on recent geany with Debian stable. I think it's fine to get merged (as it's annoying me also :) )

[b4n]

I agree those should be removed (especially as webhelper has an hard-dependency on glib-mkenums anyway), but please wait before merging, I need to check the implications on out-of-tree builds that lack the files. The problem being they are currently generated in the source directory, which is not correct if always generated.

These two get always regenerated on build on my machine with changes in the comments […].

Do you use Waf? I ever only seen the problem with Waf, which uses different paths as Autotools.
Anyway, it doesn't matter much as removing them is a good thing.

BTW @codebrainz, devhelp also has those generated files checked in, devhelp/devhelp/dh-enum-types.[ch]

[b4n]

Hum, so it's not that simple. The problem is that the generated file (webhelper/src/gwh-enum-types.c) contains translations, so we need it to build the translation catalog.
This means it either has to be distributed, or building the translation catalog requires building WebHelper.

I must say that right now I don't really see much solutions but keeping it under version control :/

[b4n]

Well, a dirty solution could be to generate them outside of WebHelper as we only need glib-mkenums which is a reasonable dependency anyway, but… that's real dirty and I'd rather not do that.

[techee]

I must say that right now I don't really see much solutions but keeping it
under version control :/

It's not such a terrible issue for me, it was just something I noticed
(using waf).

[frlan]

Would it be possible to move the translatable strings?

[b4n]

Would it be possible to move the translatable strings?

Not really, because they actually are generated. This file contains auto-generated matadata for enumerations, based on the enumeration name and value, and the translatable part is the normalized value name. For example, the enumeration below:

typedef enum {
  GWH_BROWSER_POSITION_MESSAGE_WINDOW,
  GWH_BROWSER_POSITION_SIDEBAR,
  GWH_BROWSER_POSITION_SEPARATE_WINDOW
} GwhBrowserPosition;

Generates automatically the "nicknames" of the values: "message-window", "sidebar" and "separate-window" -- and those are the ones translated (for displaying the option to the user).
So this cannot be extracted without losing the auto-generation.

[b4n]

@eht16 would it be possible to make Waf generate the files in the build directory, so they wouldn't override the ones in the source directory? This may be (also) doable with Autotools, so the version in Git would only be used when doing an in-tree build or when cloning the repo but not building WebHelper.

[codebrainz]

An alternative is to just not auto-generate the files. It's a bit more maintenance but it's quite trivial and not so much boilerplate with the current number of enumerations. On the plus side the strings could be made more meaningful for use in the GUI, for example on-connexion could become "Notify on connection".

Personally I don't care much either way, I copied this for Devhelp from WebHelper, and I'm fine copying any changes needed (or not).

[eht16]

@b4n it is possible, yet a bit hacky:

diff --git a/webhelper/wscript_build b/webhelper/wscript_build
index 8f5cded..24bb6db 100644
--- a/webhelper/wscript_build
+++ b/webhelper/wscript_build
@@ -22,7 +22,7 @@


 from build.wafutils import build_plugin
-
+import os

 name = 'WebHelper'
 sources = [
@@ -41,7 +41,7 @@ generated_sources = [
     'src/gwh-enum-types.c',
     'src/gwh-enum-types.h']

-includes = ['src']
+includes = ['src', 'generated/src']
 libraries = ['GTK', 'GLIB', 'GIO', 'GDK_PIXBUF', 'WEBKIT']
 features = ['glib2']

@@ -55,4 +55,5 @@ task = build_plugin(bld, name,
 # add generation of enums
 for generated_source in generated_sources:
     template_filename = '%s.tpl' % generated_source
+    generated_source = os.path.join('generated', generated_source)
     task.add_enums_from_template(template=template_filename, source=header, target=generated_source)

I couldn't find a cleaner way.
The above changes cause Waf to put the generated code into build/webhelper/generated/src and then add it to the list of C files to compile.

It would be nicer to tell Waf to put the generated files to build/webhelper/src directly but when trying to define bld.out_dir/webhelper/src as the target path, Waf seems to try to resolve it to an absolute path and then we get build/webhelper/build/webhelper/src which is nonsense.

So I used the "generated" prefix to trick Waf into a non-existent directory which causes it to put the results into the build dir. Not really nice but would work.

@codebrainz the Waf build system doesn't (re-)generate the enums for devhelp at build time. I didn't really read the Makefile.am but IIUC it should regenerate it like in webhelper? If so, and dependent on the outcome of this issue, I would add the missing bits to devhelp if you want.

[b4n]

I found a simpler fix: just don't put full paths in the generated output. It's not perfect in theory, but in practice it should fix all possible issues arising from this (but if glib-mkenums' output changes, but it's quite unlikely).