update wscript to work with gtk3 geany builds

[pik]

Small update to wscript to look-up which version of gtk geany was built with before configuring when using ./waf configure.
Also number of plugins don't seem to keep their wscript_configure's up-to-date, I cheated a bit by adding a function to regex it out of their .m4 build scripts. That said I'm not sure what the original logic behind having two separate build systems was or if you are still keen on maintaining it.
On a side note check_cfg_cached for gtk probably doesn't really need to be in there either probably, since geany libs and cflags would cover it.

[eht16]

Thanks for the PR, this is something I wanted to work on as well but so far didn't get to it.

What exactly do you mean by "number of plugins don't seem to keep their wscript_configure's up-to-date"?

check_cfg_cached for gtk is used by individual plugins if they require a newer version of GTK than the whole G-P defines as minimum requirement. Since we now depend on GTK 2.24 and there won't be any newer version of GTK2 ever than this, those checks are just obsolete.

A few remarks:
I would like to have the check for Geany's version in a seperate helper function, similar to target_is_win32() for easy use.

I don't like the regexp to parse the autotools build scripts. This mixes two build systems, not sure if this is a good idea. Additionally, I would like to have a clear indicator what GTK versions are supported in each plugin's wscript_configure. Better explicit than implicit.
We could add a helper function to be called from plugins' wscript_configure to signalize which GTK version the plugin supports or just add a symbol in wscript_configure to indicate this. Maybe just a tuple with GTK package names or so.

If you don't want to work on this, it might cause some work, just tell me, I can do this. No problem.

About the two build systems problem: at some point I was very impressed and fan of Waf and just added it for playing around and as an alternative to the slow autotools.
Today it is actually just annoying to maintain both build systems. But currently, Waf is the only choice to compile easily on Windows. Until this is solved, I'm afraid we have to keep it.

[pik]

What exactly do you mean by "number of plugins don't seem to keep their wscript_configure's up-to-date"?

Just that while the build/*.m4 scripts tend to have various checks at configure time, a lot of the wscript_configure files are missing these checks.

A few remarks:
I would like to have the check for Geany's version in a seperate helper function, similar to target_is_win32() for easy use.

Do you mean a different way of checking: if 'gtk-2' not in conf.env['LIB_GEANY'] ? Or just wrapping it in a function such as geany_is_gtk2() ?

I don't like the regexp to parse the autotools build scripts. This mixes two build systems, not sure if this is a good idea.

I don't really like it either - I guess my thinking was that if authors aren't maintaining wscript_configures it would be better to have a slightly magical system than no system.

If you don't want to work on this, it might cause some work, just tell me, I can do this. No problem.

About the two build systems problem: at some point I was very impressed and fan of Waf and just added it for playing around and as an alternative to the slow autotools.
Today it is actually just annoying to maintain both build systems. But currently, Waf is the only choice to compile easily on Windows. Until this is solved, I'm afraid we have to keep it.

I think Waf is pretty cool too - it would be nice if there was a way to have both without redundant maintenance though. I don't mind working on this -- the one drawback is that I don't have access to a windows machine for testing atm.

[eht16]

What exactly do you mean by "number of plugins don't seem to keep their wscript_configure's up-to-date"?

Just that while the build/*.m4 scripts tend to have various checks at configure time, a lot of the wscript_configure files are missing these checks.

If you have examples, tell us and then we can work on improving the
wscript_configure's.

A few remarks:
I would like to have the check for Geany's version in a seperate helper function, similar to target_is_win32() for easy use.

Do you mean a different way of checking: if 'gtk-2' not in conf.env['LIB_GEANY'] ? Or just wrapping it in a function such as geany_is_gtk2() ?

Right now, I don't know a better way for this check, so it is ok for me.
Just wrap it in a function. Then it is also easier later to replace it
in case we find something better.

I don't like the regexp to parse the autotools build scripts. This mixes two build systems, not sure if this is a good idea.

I don't really like it either - I guess my thinking was that if authors aren't maintaining wscript_configures it would be better to have a slightly magical system than no system.

I see. Still I personally would prefer to have the wscript_configures
maintained instead of parsing the information from another, otherwise
independent build system.

If you don't want to work on this, it might cause some work, just tell me, I can do this. No problem.

About the two build systems problem: at some point I was very impressed and fan of Waf and just added it for playing around and as an alternative to the slow autotools.
Today it is actually just annoying to maintain both build systems. But currently, Waf is the only choice to compile easily on Windows. Until this is solved, I'm afraid we have to keep it.

I think Waf is pretty cool too - it would be nice if there was a way to have both without redundant maintenance though. I don't mind working on this -- the one drawback is that I don't have access to a windows machine for testing atm.

Don't worry about the Windows part. Some of us have a working Windows
development environment, so we can work on this.

[eht16]

@pik do you still want to work on this?

[pik]

@eht16
I haven't forgotten about this - but I've been very busy lately, if someone else takes this up feel free to close this PR, otherwise I'll try to find some time to update this.

[eht16]

I guess we can close this. We will drop Waf support soon after 1.26 and so it probably isn't worth to spend more time into this.

[frlan]

This will be obsolete with removing waf right after 1.26.