MantisBT - VCMI
View Issue Details
0001886VCMIOtherpublic2014-08-29 15:112014-11-10 17:43
josch 
josch 
normalminorN/A
acknowledgedfixed 
 
0.97 
0001886: Please remove fuzzylite from vcmi and use the system version instead
Shipping embedded code copies makes it hard to find and fix security issues. Therefore, upstream projects are discouraged to ship copies of other project themselves. Here from the Debian point of view: https://wiki.debian.org/EmbeddedCodeCopies [^]

Would it be possible to remove the embedded copy of fuzzylite from vcmi?
No tags attached.
related to 0001884closed Warmonger AI/FuzzyLite is licensed Apache 2.0 which is incompatible with GPL 2.0 
Issue History
2014-08-29 15:11joschNew Issue
2014-08-29 15:40WarmongerNote Added: 0004935
2014-08-29 15:45joschNote Added: 0004936
2014-08-31 16:25IvanNote Added: 0004939
2014-08-31 16:34joschNote Added: 0004941
2014-09-02 09:12joschNote Added: 0004942
2014-09-02 12:04joschNote Added: 0004946
2014-10-25 15:05joschNote Added: 0005028
2014-10-26 13:26WarmongerNote Added: 0005032
2014-10-26 13:27WarmongerNote Edited: 0005032bug_revision_view_page.php?bugnote_id=5032#r2657
2014-10-26 13:28WarmongerRelationship addedrelated to 0001884
2014-10-26 13:30joschNote Added: 0005033
2014-10-28 20:42AVSNote Added: 0005035
2014-10-31 10:30joschNote Added: 0005044
2014-10-31 16:14WarmongerNote Added: 0005045
2014-10-31 16:14WarmongerStatusnew => resolved
2014-10-31 16:14WarmongerFixed in Version => 0.97
2014-10-31 16:14WarmongerResolutionopen => fixed
2014-10-31 16:14WarmongerAssigned To => Warmonger
2014-11-01 03:22AVSNote Added: 0005046
2014-11-01 06:05joschNote Added: 0005047
2014-11-01 07:58WarmongerNote Added: 0005048
2014-11-01 07:58WarmongerAssigned ToWarmonger => josch
2014-11-01 07:58WarmongerStatusresolved => acknowledged
2014-11-01 08:13joschNote Added: 0005050
2014-11-01 10:53crap_gamerNote Added: 0005052
2014-11-01 11:12joschNote Added: 0005053
2014-11-01 14:02crap_gamerNote Added: 0005055

Notes
(0004935)
Warmonger   
2014-08-29 15:40   
That version was added to VCMI source as there was one serious bug in original code as well as compilation issues for certain systems.
(0004936)
josch   
2014-08-29 15:45   
Which version exactly of fuzzylite is the AI/FuzzyLite directory?

Were the changes you made to it submitted to upstream?

Maybe the problems are fixed by now?
(0004939)
Ivan   
2014-08-31 16:25   
>> Here from the Debian point of view

And here is Debian point of view on fuzzylite package:
https://packages.debian.org/search?keywords=fuzzylite&searchon=names&suite=stable&section=all [^]

Not much point in doing this until at least some of somewhat popular distros will have their own copy of fuzzylite. And that's not counting our changes (don't know much about them)
(0004941)
josch   
2014-08-31 16:34   
Since I want to maintain vcmi in Debian I would also have to package fuzzylite. This is why I asked which version of fuzzylite vcmi is using. Of course if vcmi is using an ancient version of fuzzylite then it would be hard for me to convince people that this old version is needed to be in the archive and should not be updated to the most recent upstream version instead. If I package fuzzylite, then it would thus be at version 5.0. Of course this does not help vcmi much because vcmi needs an older version. And on top of that, as warmonger mentioned there are also some custom changes to it. I looked at the history and from the commit messages it seems that the first import was already a changed version and not the pristine upstream source.
(0004942)
josch   
2014-09-02 09:12   
I discovered that fuzzylite even in version 5.0 does not supply SONAME versions. This means that even if vcmi was to switch to version 5.0 of fuzzylite now, it could not reliably depend on fuzzylite as installed on the system. I reported that bug to fuzzylite together with seven other bugs I discovered in the process.
(0004946)
josch   
2014-09-02 12:04   
I did a bit archeology and found that vcmi imported some unknown fuzzylite version on 2012-03-05. The first commit to the fuzzylite git repository is for version 1.5 on 2012-08-09. By diffing files between fuzzylite in vcmi and the actual fuzzylite sources, I found that it is likely that vcmi uses a fuzzylite version prior to fuzzylite 1.5.

I also looked into porting vcmi to fuzzylite 5.0 and I agree that it will be quite the undertaking :(
(0005028)
josch   
2014-10-25 15:05   
Hope is not lost! Juan Rada-Vilela, the creator of fuzzylite was so kind to create a patch for vcmi so that it works with fuzzylite 5.0

https://github.com/vcmi/vcmi/pull/45 [^]

Once this is integrated, you can close this bugreport.

For the Debian packaging I will just manually remove fuzzylite5.0 from the vcmi tarball.
(0005032)
Warmonger   
2014-10-26 13:26   
(edited on: 2014-10-26 13:27)
I wasn't able to remove it from VCMI sources. One again FuzzyLite needs some compile tweaks (this time for Windows) and MSVS needs to build its libraries.

The main issue is hidden dependency of iso646.h

(0005033)
josch   
2014-10-26 13:30   
I saw some windows specific commits in the fuzzylite git recently. Maybe that helps. No mention of iso646.h though - maybe you can bugreport the issue so that this is fixed with the next fuzzylite release? Thanks a lot!
(0005035)
AVS   
2014-10-28 20:42   
As for me (a MinGW user) its better to keep at least my C::B project files for FL with upstream source as Git submodule. (I`ll keep it anyway even is separate repo if we decide to remove FL from source tree entirely)

P.S. with MinGW using binary releases of C++ libs (C is OK though - ABI is compatible with even any other compiler on same platform) is nearly impossible.
(0005044)
josch   
2014-10-31 10:30   
Fixing this problem was made harder by the following two lines in AI/VCAI/Fuzzy.cpp:

#include "src/Engine.cpp"
#include "src/Operation.cpp"

They were added in a commit which added support for MSVS, so maybe they should instead be surrounded by a #ifdef _WIN32 ... #endif so that they only take effect on windows.

With these two lines, vcmi requires the embedded fuzzylite copy to be present.

At least on linux, vcmi builds fine without those two #include statements.
(0005045)
Warmonger   
2014-10-31 16:14   
They seem unnecessary. Check https://github.com/vcmi/vcmi/commit/9eeea7299a111139081b88dad857f1c2f194fc83 [^]
(0005046)
AVS   
2014-11-01 03:22   
And what about #include "../../Global.h" in fuzzylite.h ?
(0005047)
josch   
2014-11-01 06:05   
And should this bugreport not only be closed once either fuzzylite is removed from vcmi or once the decision is reached that it can or should never be removed?

Did the latter happen?
(0005048)
Warmonger   
2014-11-01 07:58   
How about you tell me if it did work or not? You changed the topic.
(0005050)
josch   
2014-11-01 08:13   
Sorry, then I was unclear about the topic.

In the original report I asked whether fuzzylite could be removed from vcmi. The first problem with that was, that vcmi needed a patched version of fuzzylite and thus had to include it. This problem was solved by porting vcmi to using fuzzylite 5.0. Then there were the superficial #include statements in AI/VCAI/Fuzzy.cpp which was also resolved. Both issues made removing fuzzylite from vcmi impossible which is why I mentioned them. I did not want to change the topic, rather I wanted to see them resolved to work toward the goal of removing fuzzylite from vcmi completely as stated in the original report.

Right now, fuzzylite *can* be removed from the source and vcmi will compile using the system version of fuzzylite on linux at least.

But this bugreport is not about whether it is possible to remove the fuzzylite directory and still be able to compile vcmi (as long as fuzzylite is otherwise installed on the system) but about removing fuzzylite from the vcmi sources. I did not intend to change the topic but just point out problems in the way of reaching that goal.

So while fuzzylite can now safely be removed (on linux) I understand from the windows specific patches applied to it, that it can still not be removed completely.
(0005052)
crap_gamer   
2014-11-01 10:53   
This is output from the recent autobuild for Linux. It seems that the "../../Global.h" reference breaks things.

make -f AI/FuzzyLite/fuzzylite/CMakeFiles/fl-static.dir/build.make AI/FuzzyLite/fuzzylite/CMakeFiles/fl-static.dir/depend
make[3]: Entering directory `/build/buildd/vcmi-0.96+git20141101.3759~ubuntu14.04.1/obj-x86_64-linux-gnu'
Scanning dependencies of target fl-static
make[3]: Leaving directory `/build/buildd/vcmi-0.96+git20141101.3759~ubuntu14.04.1/obj-x86_64-linux-gnu'
make -f AI/FuzzyLite/fuzzylite/CMakeFiles/fl-static.dir/build.make AI/FuzzyLite/fuzzylite/CMakeFiles/fl-static.dir/build
make[3]: Entering directory `/build/buildd/vcmi-0.96+git20141101.3759~ubuntu14.04.1/obj-x86_64-linux-gnu'
[ 41%] Building CXX object AI/FuzzyLite/fuzzylite/CMakeFiles/fl-static.dir/src/Console.cpp.o
In file included from /build/buildd/vcmi-0.96+git20141101.3759~ubuntu14.04.1/AI/FuzzyLite/fuzzylite/./fl/Console.h:28:0,
                 from /build/buildd/vcmi-0.96+git20141101.3759~ubuntu14.04.1/AI/FuzzyLite/fuzzylite/src/Console.cpp:25:
/build/buildd/vcmi-0.96+git20141101.3759~ubuntu14.04.1/AI/FuzzyLite/fuzzylite/./fl/fuzzylite.h:33:26: fatal error: ../../Global.h: No such file or directory
 #include "../../Global.h"
                          ^
compilation terminated.
make[3]: *** [AI/FuzzyLite/fuzzylite/CMakeFiles/fl-static.dir/src/Console.cpp.o] Error 1
(0005053)
josch   
2014-11-01 11:12   
crap_gamer, you want to have a look at http://bugs.vcmi.eu/view.php?id=1924 [^] where I reported this problem.

This bugreport is only about removing the embedded copy of fuzzylite from vcmi. That the current embedded copy of fuzzylite fails to build on linux has little to do with vcmi's ability to remove fuzzylite.
(0005055)
crap_gamer   
2014-11-01 14:02   
josch; agreed.... I should have posted in the other thread/bug. I was not aware of that one. However, after have read that it seems that my info is a bit redundant anyway and that you are working on the issue..