Compiling SPARK2 from Subversion HEAD

I'm working to get SPARK2 up and running on Linux. Its currently not compiling due to a huge number of straight-up syntax errors, under both GCC 4.8 and Clang 3.3. I'm using r376.

Because as far as I can tell I'm looking at language errors, I'm wondering how anyone is actually managing to compile this thing. Can someone give me the name(s) of compilers and platforms that are known to work, and the build process? I can't decide if I'm missing something or if someone has actually been committing uncompileable code for a long time, which seems quite strange to me.

Because I haven't been able to get it to compile, I started trying to fix the failures. I've added an autotools build system and my patches so far here: https://github.com/robn/sparkengine/tree/updates

See my commits so far that fix code that shouldn't compile unless a compiler is being extremely clever/lenient (and even then I'm not entirely sure how SPK_Enum.h could ever have compiled before http://git.io/Ehtodg ).

Or it could simply be that this code isn't ready for prime-time yet and I should be using something else. But 1.5.5 and trunk are both ancient, and there's not a lot of commit activity even on the spark2 branch, so I'm at a loss.

All advice greatly appreciated. In the meantime, I'll keep trying to disentangle these non-compiling templates

Welcome,

Actually, all revision compile, but not all on every compiler. It normally compiles with VS2008, VS2010 and VS2013 I think. This compiler is also known for a bunch of language extensions... and the way it handles template lookup is more flexible than the standard (=> non-standard).

Normally, you can generate a makefile using CMake - that's why there is no makefile in the repo. Nevertheless, thanks for the fix commits, I will test them on my machine and commit that to sourceforce eventually. Seeing all these, I'm not sure all will work correctly, especially those related to the connections, will investigate this.

Note that the code is made to use no C++11 features, as some compilers were not supporting those. In the future it is highly likely that there will be a change on that (as you've probably seen, there are a lot of places where variadic templates would be very helpful...).
Also, I see that size_t commit - it will explode on 32 or 64 bit. But it reminds me that I have to finish to verify the 64bit portability...
Last, on the include policy: cpp files usually don't include their associated header, instead they include their whole module. That's why some includes appears to be missing (but that's not the case, as also you shouldn't include a specific file of the include).

edit: I fixed some errors, but there is one that will take more time to be fixed, since the fix is crashing msvc... :/

Darktib wrote:

Actually, all revision compile, but not all on every compiler. It normally compiles with VS2008, VS2010 and VS2013 I think. This compiler is also known for a bunch of language extensions... and the way it handles template lookup is more flexible than the standard (=> non-standard).

That's interesting, because it wouldn't compile out of the box for a colleague using VS2013. His guess was that it might have worked in an older compiler because his experience suggested that 2013 was getting more compliant. But he wasn't sure, and neither am I.

Quote :

Normally, you can generate a makefile using CMake - that's why there is no makefile in the repo. Nevertheless, thanks for the fix commits, I will test them on my machine and commit that to sourceforce eventually. Seeing all these, I'm not sure all will work correctly, especially those related to the connections, will investigate this.

I brought in the autotools build because its what I'm familiar with and I wanted rule out CMake as a source of problems. I don't expect you to take it. When/if I eventually pull this into my own project I'll be using my own build system, of course.

Quote :

Note that the code is made to use no C++11 features, as some compilers were not supporting those. In the future it is highly likely that there will be a change on that (as you've probably seen, there are a lot of places where variadic templates would be very helpful...).

I don't even remember what I might have used - I've been working with C++11 for so long I don't remember which things can't be used elsewhere!

Quote :

Also, I see that size_t commit - it will explode on 32 or 64 bit. But it reminds me that I have to finish to verify the 64bit portability...

Explode how? That was a tough one to figure out. On Linux size_t and unsigned int are not the same type so the compiler will not coerce them.

Quote :

Last, on the include policy: cpp files usually don't include their associated header, instead they include their whole module. That's why some includes appears to be missing (but that's not the case, as also you shouldn't include a specific file of the include).

Fair enough, I'll keep it in mind. I did what I had to do.

As it is, I stopped work on this because it'd already taken a couple of days and I got to a point that I couldn't solve without a clear understanding of the data model. I need a particle engine, but at this point its looking easier to write my own to do specifically what I need rather than spend time getting this going only to possible discard it later if its unsuitable.

That said, I'd be willing to help get it running on GCC/Clang if you're interested. I will need a fair bit of guidance though. Let me know!

robn wrote:

That's interesting, because it wouldn't compile out of the box for a colleague using VS2013. His guess was that it might have worked in an older compiler because his experience suggested that 2013 was getting more compliant. But he wasn't sure, and neither am I.

Well SPARK2 does not compile in x64 mode, so maybe that was that - because I am able to compile it in x86 mode with VS2013. I agree that it needs fixing.

robn wrote:

I brought in the autotools build because its what I'm familiar with and I wanted rule out CMake as a source of problems. I don't expect you to take it. When/if I eventually pull this into my own project I'll be using my own build system, of course.

Fair enough

robn wrote:

Explode how? That was a tough one to figure out. On Linux size_t and unsigned int are not the same type so the compiler will not coerce them.

When compiling in 32 bit mode, size_t is a typedef for unsigned int (with VS at least). Having two types that are the same in the type list breaks the meta-functions, hence it does not compile. However, in 64bit, it is not a typedef for unsigned int and so is not in the type list => if used with that system, it will not find it in the type list (obviously) resulting in a compile error.
What is needed is a clear rework of the way unsigned int / int are handled. That will surely come this year for sure.

robn wrote:

That said, I'd be willing to help get it running on GCC/Clang if you're interested. I will need a fair bit of guidance though. Let me know!

Thank you for your help ! Actually I would probably need you to test it on Linux - no code change implied, just see if it compiles / run correctly. For the moment I've fixed most of the compile error, except one that is probably a gcc bug - meaning gcc won't be supported until the bug is fixed / a reliable work-around is found. Hopefully, there is clang !
So, the commit will is post-poned to when I install clang on my Windows - that should occur quite fast normally, if possible.

Darktib wrote:

Well SPARK2 does not compile in x64 mode, so maybe that was that - because I am able to compile it in x86 mode with VS2013. I agree that it needs fixing.

My colleague did manage to get it working on VS2013 with a bit more effort. This was using my changes as well, so at least I didn't break anything!

Quote :

However, in 64bit, it is not a typedef for unsigned int and so is not in the type list => if used with that system, it will not find it in the type list (obviously) resulting in a compile error.
What is needed is a clear rework of the way unsigned int / int are handled. That will surely come this year for sure.

Right. So in one of my commits ( http://git.io/h7cVPg ) I added size_t to the list, which got it compiling for me. It also appears to have work for VS2013 in x86 mode. Is more needed than that? Or at least, will that work well enough for my purposes until you get around to fixing it properly? I'm not really keen on waiting a year!

Quote :

Thank you for your help ! Actually I would probably need you to test it on Linux - no code change implied, just see if it compiles / run correctly. For the moment I've fixed most of the compile error, except one that is probably a gcc bug - meaning gcc won't be supported until the bug is fixed / a reliable work-around is found. Hopefully, there is clang !

I'd be very interested to see that; Its pretty rare to find an actual GCC bug, though I've found some in MinGW before; mostly around mixed calling conventions. If it really is a bug you should reduce it and report it upstream.

Quote :

So, the commit will is post-poned to when I install clang on my Windows - that should occur quite fast normally, if possible.

If you put the commit up somewhere (eg a branch) I could save you some time and test it for you

First, linux portability. 64bit portability will come afterward (even if I would also prefer to finish it soon).

For the gcc bug: I posted a question on SO here: http://stackoverflow.com/questions/23525701/template-vs-non-template-class-different-behavior-across-compilers
I don't know when it will be resolved (with a bit of luck it was inadvertely fixed in 4.9 or 4.10...), so for the moment I'm fighting with clang on Windows (I used clang 3.2 but SPARK2 doesn't build on it because of a clang bug ( http://llvm.org/bugs/show_bug.cgi?id=18009 ) so now I'm compiling clang 3.4.1 to continue the port).
And I also found another clang bug btw: http://coliru.stacked-crooked.com/a/4320a36d357ad5d6 (workaround was really simple in the SPARK 2 code).

So... in 2 days I found 1 gcc bug and 2 clang bugs - I'm getting lucky... :/
Once the lib compiles I commit.


EDIT: I commited my changes, but that doesn't compile on gcc or clang (see commit log). Maybe it was because clang was not correctly configured (it is a pain in the ass on Windows, why can't they bundle correctly things ?), I don't know, but the 2 versions I tried (3.2 and 3.4.1) failed on that bug.
BTW, it still compiles perfectly on VS2010, will test VS2013 soon (don't know for VS2008 but it should compile).

I just tested, and as long as it is in 32bits, SPARK 2 compiles without warnings on VS2013.

i don't know if this is still and issue but I have spark2 working in 64 bit with vs2013 and had it working for a while for me cmake was the culprit some of the flags it turned on made the compiler throw random errors around

That's very interesting to know. Can you post more details please ?

I have a bit more time and if it can be usefull I can upload my entire spark folder for you to cheq

Yes, that can be very useful !

here we go i'm a couple revision back because I did not feel like fighting it with cmake again to get a working x64 build

also this build is for the fvf, use open mp or PPL for multi threading and contains an ebauche of my instancing and VBO usage work

https://www.dropbox.com/s/j7r2h66fwqqerlo/sparkengine.rar?dl=0

Thanks a lot, I will test this.