Gleeok wrote: @ZoriaRPG - ZC has always had the current dev branch as main in the past; we're just used it I guess. :shrug: For everyone else bitching about it during the holiday season remember that it's the holidays. Please stop bitching about it. Just swapping A<-->B around in the repo doesn't do anything. It needs some elbow grease as well. Thank you come again.
It would've saved me the trouble of getting master working, only to realize that nobody's actually using it.
I wasn't complaining. I was just responding to the "how could you possibly think nothing is happening?" sentiment, since the answer was pretty obvious from my perspective. Again, my point wasn't that you should do it, but that since it's so easy and you aren't doing it, I am obviously completely disconnected from everything and have no clue what's going on.
You know, like I said in every post I made in this thread.
LINK : fatal error LNK1104: cannot open file 'legacy_stdio_definitions.lib'
LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
LTCG in debug is crazy sauce.
edit:
2>loadpng.lib(regpng.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
2>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification
2>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
4>ffscript.ypp(596) : error C3861: 'snprintf': identifier not found
Grayswandir wrote:It would've saved me the trouble of getting master working, only to realize that nobody's actually using it.I wasn't complaining. I was just responding to the "how could you possibly think nothing is happening?" sentiment, since the answer was pretty obvious from my perspective. Again, my point wasn't that you should do it, but that since it's so easy and you aren't doing it, I am obviously completely disconnected from everything and have no clue what's going on.
You know, like I said in every post I made in this thread.
It's okay, nobody else knows what is going either.
I can fix the library issue but I don't remember the snprintf workaround. Do you know how you're fixing it in your project file?
Oh, I was just copypasta there. It's _snprintf for some reason.
Okay, on to the linker now.
Fixing legacy_stdio_definitions.lib should also fix zcsoundlib.
LINK : fatal error LNK1104: cannot open file 'Debug\zcsound.lib'
Once these link I'll test this on MSVC 2010 as well. I can also do 2013 if you like, though maybe another day.
I've pushed a fix for the libraries. Can you to regenerate/rebuild?
I'm guessing you will still get the _snprintf error though. Do you know how you fixed that?
EDIT: Oh never mind looks like you already added the necessary #defines.
It's okay, nobody else knows what is going either.
😞 Let's get to the bottom of things then...
My understanding (and correct me on any point that is wrong):
1. The public releases of ZC lately (2.50.3, etc) have been based on the 2.50.x branch of the repository.
2. Independently, Gleeok and others have been committing new features/fixes to the master branch of the repository.
3. The master branch contains many valuable changes.
4. The master branch also contains some changes that are considered by Saffith (and perhaps other) as "garbage."
5. 2.50.x contains changes that have not been applied to master.
So where does that leave us? Clearly 2.50.x (with cleanup which we're currently undertaking) must become the master branch, since that is the branch from which public binaries are actually being published. We cannot use the code from the current master branch for at least two reasons:
- it is not in sync with the current publicly-released binaries;
- some of the changes are "garbage" and need to be reconsidered.
Hence the plan to make 2.50.x the new master, and to look through the current-master changes and incorporate those that are worthwhile, while avoiding the garbage. Once that is done, the repository will be in a healthy state and we can start e.g. discussing changing the Allegro version or pulling in some of ZoriaRPG and Grayswandir et al's changes.
If I've gotten something wrong or you disagree with any of the above, by all means, please let me know.
DarkDragon wrote:I've pushed a fix for the libraries. Can you to regenerate/rebuild?I'm guessing you will still get the _snprintf error though. Do you know how you fixed that?
EDIT: Oh never mind looks like you already added the necessary #defines.
I've got it compiled for 2008. I'll try 2010 and also update the source later with my changes. Congrats, you are the first person in the history of CMAKE to actually make some c++ nonsense work. (Not joking, it's always usually awful) Thanks!
(Although the build times are too long,~I can just fix that later.)
DarkDragon wrote:😞 Let's get to the bottom of things then...My understanding (and correct me on any point that is wrong):
1. The public releases of ZC lately (2.50.3, etc) have been based on the 2.50.x branch of the repository.
2. Independently, Gleeok and others have been committing new features/fixes to the master branch of the repository.
3. The master branch contains many valuable changes.
4. The master branch also contains some changes that are considered by Saffith (and perhaps other) as "garbage."
5. 2.50.x contains changes that have not been applied to master.
So where does that leave us? Clearly 2.50.x (with cleanup which we're currently undertaking) must become the master branch, since that is the branch from which public binaries are actually being published. We cannot use the code from the current master branch for at least two reasons:
- it is not in sync with the current publicly-released binaries;
- some of the changes are "garbage" and need to be reconsidered.
Hence the plan to make 2.50.x the new master, and to look through the current-master changes and incorporate those that are worthwhile, while avoiding the garbage. Once that is done, the repository will be in a healthy state and we can start e.g. discussing changing the Allegro version or pulling in some of ZoriaRPG and Grayswandir et al's changes.
If I've gotten something wrong or you disagree with any of the above, by all means, please let me know.
That's basically what I was thinking.
Thanks Gleeok! Let me know if you run into any new trouble with 2010.
ZoriaRPG, you mentioned that you used a Mac. Do you have time to take a stab at adding OS X support to CMakeLists.txt? I know that OS X uses -frameworks and all kinds of other delights I'm ignorant about :-/
On VC 2010 I get a wall of
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(59): error C2628: '_Longlong' followed by 'signed' is illegal (did you forget a ';'?)
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(59): error C2628: '_Longlong' followed by '__int64' is illegal (did you forget a ';'?)
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(59): warning C4091: 'typedef ' : ignored on left of '__int64' when no variable is declared
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(60): error C2628: '_ULonglong' followed by 'unsigned' is illegal (did you forget a ';'?)
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(60): error C2628: '_ULonglong' followed by '__int64' is illegal (did you forget a ';'?)
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(60): warning C4091: 'typedef ' : ignored on left of 'unsigned __int64' when no variable is declared
I'm 2/2 on here and I also had this problem on the trunk once. IIRC so did someone else. It's defining those AND then including stdint.h (Which I believe is included as part of the c library by clib headers.) The astdint.h file is to blame. If anyone ever includes any other reasonable header after an allegro header this is going to happen.
If there's no problem I'd like to remove that and force users to have stdint.h. For MSVC 2005/2008 I can add a suitable al_stdint.h into the allegro/platform folder.
[EDIT] Nevermind. That did not work. Seems to only be 64 bit types (I missed that - Doh!). Now who's the culprit here...
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. 😊
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.
Gleeok wrote: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.
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.
DarkDragon wrote: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?
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.
Gleeok wrote: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?
Saffith wrote: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.
Gleeok wrote: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.
DarkDragon wrote: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/ZeldaClassic/tree/master/src/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).
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.
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.
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.
I just did. Sorry for the delay.
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.
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 :P )
Gleeok wrote:I don't know if anyone has built romview in years.
I've got it building just fine?
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.
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.