Building on Mac and Linux

[Gleeok]

Found it:

#define LONG_LONG    __int64

// MSVC now has these built in
#if _MSC_VER < 1900
#define int64_t      signed __int64
#define uint64_t     unsigned __int64
#endif

allegro4 is now my least favorite media library.


Still get the LINK : fatal error LNK1104: cannot open file 'legacy_stdio_definition error

[EDIT] Fixed it.

[EDIT2] Okay, cmake should build on older MSVC conpilers up to 2013 now. :)

[DarkDragon]

I've added support in CMake for building the ZScript lexer and parser using Flex and Bison.

Install these tools if you haven't already (https://sourceforge.net/projects/winflexbison/) and add the folder containing win-flex.exe and win-bison.exe to your PATH environment variable. CMake should detect the presence of Flex and Bison and generate the parser files.

If you do not have Flex and Bison, ZQuest will still build fine, but will not be able to compile ZScripts.

[DarkDragon]

Found it:

#define LONG_LONG    __int64

// MSVC now has these built in
#if _MSC_VER < 1900
#define int64_t      signed __int64
#define uint64_t     unsigned __int64
#endif

allegro4 is now my least favorite media library.


Still get the LINK : fatal error LNK1104: cannot open file 'legacy_stdio_definition error

[EDIT] Fixed it.

[EDIT2] Okay, cmake should build on older MSVC conpilers up to 2013 now. :)

Great! I'm guessing some of those _MSC_VERs were slightly wrong?

Let me know when you've pushed your changes and I'll check everything still builds on my end.

[Gleeok]

It should. I committed all the CMake related changes. The rest is just source tweaks. Hopefully one of the linux guys can drop in and test it out as well. :)

I'm comparing build times right now. Cmake: ZC only build (in cache) 72 sec. My project version: ZC only build (in cache) 17 sec. So I'm going to stick with this for the time being, but I'll be happy to help keep CMakeLists up to date.

[Gleeok]

I've added support in CMake for building the ZScript lexer and parser using Flex and Bison.

Install these tools if you haven't already (https://sourceforge.net/projects/winflexbison/) and add the folder containing win-flex.exe and win-bison.exe to your PATH environment variable. CMake should detect the presence of Flex and Bison and generate the parser files.

If you do not have Flex and Bison, ZQuest will still build fine, but will not be able to compile ZScripts.

Is adding in another 3rd party dependency a good idea? Is it possible to set CMake to build with flex/bison only if the user wants/has it, otherwise just use the current ones from src/parser/ instead?

[Saffith]

For my part, I pretty much don't care. There's nothing I care to see kept, and I don't care if I can compile it.
If stuff still needs fixed, I'll do what I can. I don't really know much about the Mac stuff, though. I fiddled with it enough to get it working and then just left it alone.

[DarkDragon]

It should. I committed all the CMake related changes. The rest is just source tweaks. Hopefully one of the linux guys can drop in and test it out as well. :)

I'm comparing build times right now. Cmake: ZC only build (in cache) 72 sec. My project version: ZC only build (in cache) 17 sec. So I'm going to stick with this for the time being, but I'll be happy to help keep CMakeLists up to date.

Can you explain what you did to speed up your compilation time? Did you turn on precompiled headers, or do something else? I can include it in the CMake.

Keeping the separate project is just asking for trouble.

EDIT: I've pushed support for the precompiled header someone (you?) set up for ZC and ZQuest. Can you check if the build still works? Does it help your build speed at all?

[DarkDragon]

For my part, I pretty much don't care. There's nothing I care to see kept, and I don't care if I can compile it.
If stuff still needs fixed, I'll do what I can. I don't really know much about the Mac stuff, though. I fiddled with it enough to get it working and then just left it alone.

Hi Saffith,

Can you elaborate on your post? You don't care about ZC development overall? About what features to keep from current-master? About something else?
Even if you are no longer interested in developing ZC, your thoughts about which changes in current-master are or are not worthwhile would be very useful.

[DarkDragon]

Is adding in another 3rd party dependency a good idea? Is it possible to set CMake to build with flex/bison only if the user wants/has it, otherwise just use the current ones from src/parser/ instead?

Flex and bison are not new dependencies per se; they've always been needed to compile the ZScript stuff. But, I understand your concern (and am even less of a fan of extra dependencies than you are, probably )

Checking for flex and bison is intended to fix three kinds of problems someone checking out the repository might run into:
- they edit the .lpp or .ypp file and expect to see some changes in ZQuest;
- they directly edit the y.tab.cpp file, and then they don't understand why their changes keep getting overwritten. (Even Dark Nation was notorious for this particular slip-up.)
- the *do* figure out they need to run Flex and Bison on the .lpp and .ypp files, but they use their OS's version of Flex and Bison which adds all kinds of <unistd> nonsense that will not compile on Windows.
And of course when this happens we have to deal with the complaints.

Checking for Flex and Bison means that if someone downloads the source and just wants to play around without installing (too many) third-party dependencies, ZC will work 100% right and ZQuest will also work, except for the ability to compile new ZScript scripts. If they become serious about modding ZC they will then have to go and install the Flex and Bison package.

But if you feel strongly against this approach, let me know.

[Gleeok]

Can you explain what you did to speed up your compilation time? Did you turn on precompiled headers, or do something else? I can include it in the CMake.

Keeping the separate project is just asking for trouble.

EDIT: I've pushed support for the precompiled header someone (you?) set up for ZC and ZQuest. Can you check if the build still works? Does it help your build speed at all?

Yep, indeed that was me that added precompiled header support to ZC. The problem I had with this is that pch* does not really benefit ZC in particular that much, so I switched to unity building. The tricky part about doing this in ZC is what grouping and how many files you can combine together, but it works as more art than science in ZCs case. Take a look at master/src/build_modules for reference https://github.com/ArmageddonGames/Z.../build_modules ; The idea was to not only speed up compiles/linking but also simplify building the source; ie., just build all the zc_* prefixed cpp files for ZC, and build the zq_* prefixed files for ZQuest. I was trying to make it easy to set up new builds for different platforms as well. I'll add the modified files to the cmake branch in case.

So, in short, I don't use PCH for ZC since it doesn't help much, however I kept it in so you just have to #define PCH (and maybe modify precompiled.h to be better).