adapt Hugin to changes in Enblend/Enfuse 4.0 parameters

[Yuv]

With the evolution of enblend-enfuse to 4.0 some of the switches behave differently. Hugin currently generates all enblend/enfuse parameters for the 3.x version.
We need:
- to identify the version installed (with --version)
- to determine what it can and can't do (e.g. zenith/nadir blending that are available in 4.0 but not in 3.x)
- to lay out rules of what switches are passed to which version of enblend/enfuse

[Bruno Postle (brunopostle)]

Detecting versions and changing behaviour is problematic. Better to require a particular version of enblend, we can make the Makefile stitching test fail with the old version.

e.g. `enblend --version` fails with enblend-3.2, if it passes with 4.0 then we have a valid test.

[Yuv (yuv)]

detecting versions and changing behavior is a way to make this viable over multiple (and inevitable) changes in tools that we do not control.

just a failing test for enblend 3.x will be ok for 4.0, but when 4.1 introduces new switches (e.g. for deghosting) we need to know what can and what can't be fed to it.

[Bruno Postle (brunopostle)]

Requiring specific versions of software isn't a problem so long as there is a 'stable' enblend release that we can require.

Packagers need to either include the right version of enblend-enfuse or use a packaging system that enforces the requirement (rpm/deb).

[Pablo d'Angelo (pablo.dangelo)]

I consider this specific issue a bug in enblend (btw. the enblend bug tracker seems to be empty!)
The documentation says:
"Specifying --wrap without MODE selects horizontal wrapping."
So it should be possible to specify just -w, or --warp. If it treats the next option (starting with a dash) as MODE argument, then this behaviour is IMHO not correct and should be fixed in enblend

This bug should be moved to the enblend tracker.

Backward compatability is something important, and it shouldn't be needlessly thrown out of the window. This will affect not only hugin but also all other uses of enblend.

[Yuv (yuv)]

@Bruno: OK.

@Pablo: it's the enblend *support* tracker that has been emptied. Enblend now follow the convention of other SF projects (including Hugin) and has a proper *bug* tracker (menu Tracker -> Bugs) here
https://sourceforge.net/tracker/?group_id=123407&atid=696409

I'll "move" the bug there

[Yuv (yuv)]

Agree with Bruno's comment #1 - on systems with proper package management we can require a particular version. On system without proper package management we can point the users to get the proper version

[Yuv (yuv)]

what was I thinking when I set this to affect enblend but not hugin? in Hugin we could look at the output of the version number before proceeding with the blending in the makefile.

[Yuv (yuv)]

http://stackoverflow.com/questions/1864385/how-to-force-an-error-in-a-gnumake-file

we can't assume sed available on Windows, so we need some other way to check, but I would like to add something like the above into the Makefile.

[tmodes (tmodes)]

The packages should enforce a specific version. So I don't see a point to add it to each run of the makefile.