0001886: Please remove fuzzylite from vcmi and use the system version instead

Notes
(0004935) Warmonger (administrator) 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 (developer) 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 (developer) 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 (developer) 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 (developer) 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 (developer) 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 (developer) 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 (administrator) 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 (developer) 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 (administrator) 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 (developer) 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 (administrator) 2014-10-31 16:14	They seem unnecessary. Check https://github.com/vcmi/vcmi/commit/9eeea7299a111139081b88dad857f1c2f194fc83 [^]

(0005046) AVS (administrator) 2014-11-01 03:22	And what about #include "../../Global.h" in fuzzylite.h ?

(0005047) josch (developer) 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 (administrator) 2014-11-01 07:58	How about you tell me if it did work or not? You changed the topic.

(0005050) josch (developer) 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 (reporter) 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 (developer) 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 (reporter) 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..

Issue History
Date Modified	Username	Field	Change
2014-08-29 15:11	josch	New Issue
2014-08-29 15:40	Warmonger	Note Added: 0004935
2014-08-29 15:45	josch	Note Added: 0004936
2014-08-31 16:25	Ivan	Note Added: 0004939
2014-08-31 16:34	josch	Note Added: 0004941
2014-09-02 09:12	josch	Note Added: 0004942
2014-09-02 12:04	josch	Note Added: 0004946
2014-10-25 15:05	josch	Note Added: 0005028
2014-10-26 13:26	Warmonger	Note Added: 0005032
2014-10-26 13:27	Warmonger	Note Edited: 0005032	View Revisions
2014-10-26 13:28	Warmonger	Relationship added	related to 0001884
2014-10-26 13:30	josch	Note Added: 0005033
2014-10-28 20:42	AVS	Note Added: 0005035
2014-10-31 10:30	josch	Note Added: 0005044
2014-10-31 16:14	Warmonger	Note Added: 0005045
2014-10-31 16:14	Warmonger	Status	new => resolved
2014-10-31 16:14	Warmonger	Fixed in Version	=> 0.97
2014-10-31 16:14	Warmonger	Resolution	open => fixed
2014-10-31 16:14	Warmonger	Assigned To	=> Warmonger
2014-11-01 03:22	AVS	Note Added: 0005046
2014-11-01 06:05	josch	Note Added: 0005047
2014-11-01 07:58	Warmonger	Note Added: 0005048
2014-11-01 07:58	Warmonger	Assigned To	Warmonger => josch
2014-11-01 07:58	Warmonger	Status	resolved => acknowledged
2014-11-01 08:13	josch	Note Added: 0005050
2014-11-01 10:53	crap_gamer	Note Added: 0005052
2014-11-01 11:12	josch	Note Added: 0005053
2014-11-01 14:02	crap_gamer	Note Added: 0005055