Compiling on Windows using MinGW/MSYS2


#1

I think that we ought to be able to get MeTA working on Windows now, particularly under the MinGW/MSYS2 environment, since they should be using a recent enough GCC-based toolchain.

The only real major issue that I can think of are ourmmap() calls used in both mmap_file and disk_vector, but I think we might be able to use the mman-win32 project to make porting pretty easy, and the license is compatible so we should be good to go.

We’ll need to make changes to the CMakeLists.txt obviously to accomodate, but it is probably easier to get this working than getting Visual Studio at the moment (although that situation may have changed recently with their 2015 RC release?)

Any takers? This would be great for the toolkit, since we’ll then be able to be compiled natively on all three major platforms (Linux, OSX, and Windows). There’s even a service we can use for doing CI on Windows called Appveyor.


#2

So I let the curiosity get the best of me and tried the above. It seems to work: I’m able to cross-compile for Win64 from my Linux machine. It required some massaging of the sources (and pulling in the sources from mman-win32) and is available in the mingw64 branch.

I haven’t actually tested anything, since I don’t have Wine installed (and don’t want to)… but this seems to suggest that we’re very close to being able to support Windows, at least with GCC as the compiler.

I’d be lovely to see what MSVC’s status is, but I don’t feel too strongly about pursuing that if we’re able to compile using an open-source toolchain on the platform. I promise I’ll leave that to someone else. =)


#3

(Here’s the MSVC status for RC 2015: http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx)


#4

OK, I’ve now actually tested things on Windows 7 using the MSYS2 environment. As of this commit, the unit tests actually pass for MeTA in that environment!

I’ll write a tutorial on how to get this built on Windows in the documentation category, and I’ll be making it a wiki in case people want to modify it to include instructions for, say, VS 2015 RC.

I’m not going to bother with Appveyor for now, since it seems like getting MSYS2 working on that CI platform is more trouble than it’s worth. I’ll be making a best-effort attempt to ensure that the code at least compiles in Windows before merges to master.


#5

Hi! I would love to have META available for Windows and, more precisely, to be able to compile and develop using Visual Studio (now I’m working with MSVS 2013).

I would like to know how can I help or where to start. Any advise would be really apreciated.

Thanks for the library and the effort!


#6

I’m inclined to believe that you’ll have better luck with MSVC 2015, since there were a lot of bug fixes between 2013 and 2015 (at least, according to the standard library maintainer).

Do you have the ability to test with MSVC 2015, or are you stuck with 2013 for a specific reason?

In terms of what you could do to help, we’d need to go through the compiler errors one by one, so the first thing that’d be helpful would be to see a log of the compilation process if you try to use MSVC. That’ll give us some place to start. Maybe throw that up on a Pastebin or Gist?

If you’re comfortable enough making changes, I’d welcome any pull requests that fix build errors on MSVC. In theory things should be cross platform enough that it should just require minor fixes, but that really depends on how conforming MSVC is at this point.


#7

I’ll try with MSVC 2015 Community, I’ll keep you updated. Which repo/branch should I push any pull-request to?


#8

The main repo at meta-toolkit/meta is fine, and targeting branch develop.

(You’ll also want to be building the develop branch as opposed to master.)

Thanks!


#9

This gist shows the errors obtained when compiled with MSVC2015.

CMake 3.1.0
icu4c-55.1

I will try to address those errors and make a pull request ;D Of course, any help or advice will be appreciated.


#10

I’m facing a problem with the very first source file: include/meta.h and include/utils/identifiers.h. I need to ask because I think I haven’t got enough knowledge about C++14 and the problem is related to it.


Issue #1:

    template <template <class> class Wrapped>
    struct hash_wrapper : public Wrapped<hash_wrapper<Wrapped>>
    {
        using Wrapped<hash_wrapper>::Wrapped;
        using Wrapped<hash_wrapper>::operator=;

        hash_wrapper() = default;
            hash_wrapper(const hash_wrapper&) = default;
            hash_wrapper(hash_wrapper&&) = default;
            hash_wrapper& operator=(const hash_wrapper&) = default;
            hash_wrapper& operator=(hash_wrapper&&) = default;
        };

It fails at several points with this message:

util/identifiers.h(49): error C2039: 'Wrapped': is not a member of 'meta::class_label_dummy<meta::util::hash_wrapper<meta::class_label_dummy>>'

This is like a trap where Wrapped type must declare a member Wrapped :S I don’t even know if this using declaration is needed


Issue #2:

There are a lot of errors like this:

~\src\io\libsvm_parser.cpp(65): error C2440: 'initializing': cannot convert from 'initializer list' to 'meta::util::hash_wrapper<meta::term_id_dummy>'
   ~\src\io\libsvm_parser.cpp(65): note: No constructor could take the source type, or constructor overload resolution was ambiguous

Following the sources I have arrived to identifier struct where there is an explicit constructor defined as

template <class Derived, class T>
struct identifier : public comparable<identifier<Derived, T>>
{
    ...
    explicit constexpr identifier(const T& t) : id_{t}
    {
        // nothing
    }
    ...
};

I don’t know if MSVC is a lot more strict with constructors…


Without solving these issues I cannot do much more.

Thanks for your help.


#11

I assume issue #1 and issue #2 are really the same thing (in that I think the first issue is likely causing the second).

This code was a) old and b) bad, so you’ve finally motivated me to update it. I think the latest commits to develop (specifically, this one) might fix this issue for you.

If it doesn’t, at least it should be easier to comprehend now, which might make solving the issue easier.

Let me know if that helped any.


#12

Thanks for the commit, it actually helped and now I’m able to start compiling the sources. I have to get familiar with all the advanced C++ stuff because there are a lot of thing I’m finding quite difficult to understand (but I have to learn and improve my programming skill, so this is perfect for me).

I’ve made a commit to move some includes to .h file because they were needed in two different .cpp files (filesystem.cpp and mmap_file.cpp). I prefer having all the stuff needed by a file in the header, but I know that some people prefers to have headers free of includes and put all of them in .cpp files… Is there an strict rule in this sense?

I have to make a lot of tiny changes for this project to compile, I think that I will make them all on tiny commits and, if you want, we can discuss each of them over the source code. It will be easier, won’t it?


#13

I’ve opened this pull-request [1] in order to work in this issue. Anyone is welcome to contribute and help

[1] https://github.com/meta-toolkit/meta/pull/115


#14

Typically I will prefer to keep header pollution down to a minimum, but I don’t go to extreme lengths to forward-declare everything either. I guess that means there isn’t really a hard-and-fast rule, but just use your best judgment. I’ll point out stuff if it bugs me.

Yep, that’s great. Thanks!


#15

So I’ve got AppVeyor working with MSYS2 for providing CI against Windows for now. I’ve also added a build guide to the README in the develop branch.

When we merge develop into master (soon…), I’ll create an entry on the website for building in Windows, too.

It would be great to support MSVC (looking forward to @jgsogo’s patches) , but at least people can use the toolkit with a compiler on Windows now. =)