Building on Mac and Linux

[DarkDragon]

You have this set up on 2.50.x? Or just master?

In other words, if the source files are already in a state where they can be easily unity'd together, I can add a unity configuration right away. If there are #define and global variable conflicts galore that require fixes from the master branch, let's finish getting the cmake branch working for most people and then make incorporating the source tree changes a high-priority follow up.

[Gleeok]

That would be great!

I set it up yesterday for the 2.50.x branch. I'll commit them in a bit.


[edit]
Beware of just including everything though, you will get a wall of compiler nonsense. That's the reason I couldn't just add in a zc_unity.cpp and tell people they can just build that if they have an odd toolchain or platform or whatever. This is another reason I really, really hate global pollution, and I'm always anal-retentive about sneaky #defines or "using" in global scope.

[DarkDragon]

Ok let me inspect how you group the files and set up a configuration.

EDIT: It looks like you'll need to commit your module source files; I see the MSVC 2008 project in projects/vs2008 but not the sources.

[Gleeok]

I just did. Sorry for the delay.

[DarkDragon]

Ok. Tick the "UNITY_BUILD" checkbox when you run CMake and it should make a unity build MSVC project file for you.

A couple of notes:
- I had to tweak your snprintf fix to get it to work on my end. You may have to adjust it further if I got the version number wrong.
- The files you pushed leave jwin.cpp and zq_rules.cpp out of the unity build. Under the assumption that you had good reasons, I did the same.
- Several files in romview were causing drama, so I pulled them out rather than trying to figure out how to fix the clashes.

[Gleeok]

I don't know if anyone has built romview in years.

I condensed a few files and forgot about those cpp files. I'll still sort of be mucking with those files for a bit -- the 2.50 source structure is different enough I'll probably do a dump of all the preprocessed sources again to get it reasonable.

So how does it work in CMake? I can just directly edit those .cpp files without changing anything else right?

Thanks for all your help. Let us know when you consider this good enough to swap with the master branch. (aka; crash test cmake )

[Grayswandir]

I don't know if anyone has built romview in years.

I've got it building just fine?

[DarkDragon]

So how does it work in CMake? I can just directly edit those .cpp files without changing anything else right?

Pretty much. If you want to edit a "standard" .cpp or .h file (zelda.cpp etc) you just do it directly in MSVC.

If you want to add a new .cpp file, edit the CMakeLists.txt and add it to the appropriate source file group (should be obvious where to put it). In most cases the next time you compile your code on MSVC, MSVC will automatically detect that the CMake file has changed and update itself to add the new file, and will also automatically add the file to the appropriate unity module.

If you want to change configuration options or flags, you need to do it in CMake, otherwise 1) your changes won't be seen by the repository and 2) they will get overwritten next time you run CMake. I'm happy to help figuring out how to change settings if needed.

[DarkDragon]

I will (re)check that everything still builds on Ubuntu later today.

EDIT: Made a couple of small fixes, and now Linux build works. I still don't have sound, but that seems to be a long-standing problem.

@everyone else: if you are using Windows with MinGW, or Mac OS X, or some other platform, and care about being able to build the source in the near future, please speak up. We will drop official support for platforms lacking developers actively interested in supporting that platform.