PDA

View Full Version : Building on Mac and Linux



DarkDragon
12-23-2016, 04:17 AM
Saffith and Gleeok, what procedure do you use to build the source on Linux or OS X? How do you handle Allegro and its fix.sh etc?

Saffith
12-23-2016, 04:42 PM
There's a compiled Allegro for Linux in the 2.50.x branch.

It's been a long time since I built it, and I don't have the configuration log. I think it's configured with
./configure --enable-static=yes --enable-shared=no --enable-ossdigi=no --enable-ossmidi=no --enable-esddigi=no --enable-artsdigi=no --enable-sgialdigi=no --enable-jackdigi=no --enable-xwin-dga2=no --enable-vga=no --enable-svgalib=no
There's a problem with the makefile that current versions of make won't overlook:

clean:

define RM_OBJ_CLEAN_FILES
$(foreach file, $(OBJ_CLEAN_FILES), rm -f $(file)
)
endef

define RM_OTHER_CLEAN_FILES
$(foreach file, $(OTHER_CLEAN_FILES), rm -f $(file)
)
endef

$(RM_OBJ_CLEAN_FILES)
$(RM_OTHER_CLEAN_FILES)

distclean: clean

define RM_DISTCLEAN_FILES
$(foreach file, $(DISTCLEAN_FILES) $(ALLEGRO_LIB_X_EXES), rm -f $(file)
)
endef

$(RM_DISTCLEAN_FILES)

veryclean: distclean

define RM_VERYCLEAN_FILES
$(foreach file, $(VERYCLEAN_FILES), rm -f $(file)
)
endef

$(RM_VERYCLEAN_FILES)
rm -f makefile

should be


define RM_OBJ_CLEAN_FILES
$(foreach file, $(OBJ_CLEAN_FILES), rm -f $(file)
)
endef

define RM_OTHER_CLEAN_FILES
$(foreach file, $(OTHER_CLEAN_FILES), rm -f $(file)
)
endef

define RM_DISTCLEAN_FILES
$(foreach file, $(DISTCLEAN_FILES) $(ALLEGRO_LIB_X_EXES), rm -f $(file)
)
endef

define RM_VERYCLEAN_FILES
$(foreach file, $(VERYCLEAN_FILES), rm -f $(file)
)
endef

clean:
$(RM_OBJ_CLEAN_FILES)
$(RM_OTHER_CLEAN_FILES)

distclean: clean
$(RM_DISTCLEAN_FILES)

veryclean: distclean
$(RM_VERYCLEAN_FILES)
rm -f makefile


On Mac, you have to install Allegro as an embeddable framework, which is just a matter of
make install-framework EMBED=1
The default config options should be fine. I don't believe there was anything else special there, but I built it on 10.6.8. No idea how it'll go on a newer version.

DarkDragon
12-23-2016, 05:30 PM
Ok, thanks.

Do either of you still use MINGW on Windows?

Gleeok
12-24-2016, 03:24 AM
I don't very often. I think I only keep it around to keep code from being non-portable. The link times on 4.5++ gcc infuriate me.

Also, I run windows XP right now on my "dev machine". Pretty cool huh? :P (Long story that ends in tragedy. Short version is hardware problems on 4 computers the last few years; but I've still got old faithful here!)

I also have a big-ass Mac something...[ not hooked up; I hate Macs] and a Windows 10 laptop with a bunch of broken keys so it's only good for media.

DarkDragon
12-24-2016, 09:28 PM
Ok. As a first step to fixing the repository, I've created a CMake script that, for me at least, compiles the code on Windows and on Ubuntu. I've also taken a stab at some build instructions (in README.mk).

https://github.com/ArmageddonGames/ZeldaClassic/tree/cmake
Gleeok, could you please check if CMake correctly generates the project files for your version of Windows and MSVC (and that the resulting project files compiles the code correctly)? Saffith, unfortunately I don't own a Mac. Could you please take a stab at adding the OS X-specific settings to the CMakeLists.txt?

Once we iron the kinks out, we can make this branch the new master.

DarkDragon
12-25-2016, 05:11 AM
Whoops, posted this in the wrong forum. Moved to ZC Development.

Grayswandir
12-25-2016, 10:59 AM
Just wanted to pop in here, I have a makefile working for linux: https://github.com/gwx/ZeldaClassic/tree/active.
I completely tore up the old makefile in trying to get it to work, so it's not recognizably the same. It also lets you switch between allegro 4.2 and allegro 4.4, and has a few other switches set up to turn debug symbols off/on, etc.
I've been trying to schedule some time on a windows machine so I can get it working for windows as well.

ZoriaRPG
12-25-2016, 01:58 PM
I'm going to be stuck doing the Mac stuff, most likely. I have 10,4, 10.5, and 10.6 systems, so compiling it on a newer version won't be the issue. Frack, I want to see if it will work s a Univ Bin. I don't think endianness should be a huge issue, as @Takyua managed to do it years ago (b895). Not sure if he had to do anything fun other than direct the compiler.

DarkDragon
12-25-2016, 03:53 PM
Just wanted to pop in here, I have a makefile working for linux: https://github.com/gwx/ZeldaClassic/tree/active.
I completely tore up the old makefile in trying to get it to work, so it's not recognizably the same. It also lets you switch between allegro 4.2 and allegro 4.4, and has a few other switches set up to turn debug symbols off/on, etc.
I've been trying to schedule some time on a windows machine so I can get it working for windows as well.

What is the advantage of Allegro 4.4 over Allegro 4.2?

One thing currently missing from the CMake file is the compilation of the parser files using Flex and Bison. I'd like to include this, with graceful degradation to using the pre-generated files in case the user does not have flex or bison installed.


I'm going to be stuck doing the Mac stuff, most likely. I have 10,4, 10.5, and 10.6 systems, so compiling it on a newer version won't be the issue. Frack, I want to see if it will work s a Univ Bin. I don't think endianness should be a huge issue, as @Takyua managed to do it years ago (b895). Not sure if he had to do anything fun other than direct the compiler.

The old Makefiles have a target for Mac OS Universal. Does it still work? There only place where the endianness really matters is in the quest loading and saving. We fixed a lot of these bugs back in the day, so there's a good chance the code will still work on a big-endian platform, but of course it would need extensive testing to ensure there is no quest file corruption before we officially support it.

ZoriaRPG
12-25-2016, 07:33 PM
What is the advantage of Allegro 4.4 over Allegro 4.2?

One thing currently missing from the CMake file is the compilation of the parser files using Flex and Bison. I'd like to include this, with graceful degradation to using the pre-generated files in case the user does not have flex or bison installed.



The old Makefiles have a target for Mac OS Universal. Does it still work? There only place where the endianness really matters is in the quest loading and saving. We fixed a lot of these bugs back in the day, so there's a good chance the code will still work on a big-endian platform, but of course it would need extensive testing to ensure there is no quest file corruption before we officially support it.

I'm pretty sure that officially supporting PPC architecture is a bit too far-reaching. Just having it as an option is good, but it's for the two people, meself included, that still run a G5 system. Mainly, I want to benchmark ZC on a G5, and for giggles, on a G4. If it tests good, I suppose allowing general use is fine, but I doubt many people would download it, unless it benchmarks very well on a 1GHz G4, and people want to play quests on old iBook systems or Powerbookes?

I doubt heavily scripted quests would run well on less than a 1.67GHz 4, or a G5.

I'd be more concerned that the libraries aren't set up for universal binary use.

Allegro 4.4 has a ton of bugfixes that should resolve several longstanding bugs in ZC, plus new drawing modes, support for other goodies, more stability, better graphical library implementation, and did I mention ten years worth of bugfixes that we're ignoring, and trying to fix around on the ZC engine side, instead of fixing them at the source?

That binary that I want you to test uses 4.4.3. Running that fixed two distinct input bugs, and prevented the most common WIn8+ graphical bugs in fullscreen. THat's why I wanted you to test it, because if it doesn't exhibit the crashing behavior that you have with 2.50.3, then that's all the more reason to finish the conversion. We're probably 90% done as it stands.

Fixing compilation of the parser files, both in the general makefile, with an extra pass, and a CMake file is a good priority. let it be automatic, so that the user doesn't need to manually do multiple compilations on the package.

DarkDragon
12-25-2016, 07:38 PM
What conversion is needed? 4.4 API is not backwards compatible with 4.2?

DarkDragon
12-25-2016, 07:44 PM
In any case, one incremental step at a time. My main concern in this thread is getting a sane build system set up that works with the platforms we currently support. Once that is done, we can clean up the repository structure, and *then* discuss swapping out libraries.

ZoriaRPG
12-25-2016, 07:48 PM
What conversion is needed? 4.4 API is not backwards compatible with 4.2?

The main thing, was adding functions to handle the packfile password junk. That's done. At present, IDK why the audio libs are crashing on the Win platform, and Grayswandir is having different issues with audio on Linux. I think that Allegro itself is fine now, but finishing up the other libs mayn't be.

It feel as if GME is causing the problems, but I'm unsure. We need to update that, too. We're a dozen releases back, and the newer version is more stable, with better output, and more supports more formats, including NSFE.

Did you try running those binaries? Maybe you can debug why playing any NSF causes them to crash. If you want all the allegro stuff and the makefile that I'm using to process ZC, I can pack it all up for you. In fact, it is probably here:

http://timelord.insomnia247.nl/zc/zc_dev/ZC_2.54_Sources_Beta_39_Allegro_4.4.3.zip

This relates to these log entries for ag4.4:



Eliminated the need for old DirectX headers for the Windows port (David Capello).

Fix problems in Windows when you use Alt-Tab. Sometimes the Alt modifier is kept pressed when you focus the Allegro window. (David Capello)


The latter of these two issues was a very annoying bug in ZC/ZQuest, and the former helps fix some graphic badness.

The makefile should be in there, I build Allegro following the instructions here (http://liballeg.org/stabledocs/en/build/cmake.html), here (https://wiki.allegro.cc/index.php?title=Build/MinGW), and here (https://www.allegro.cc/forums/thread/615640) using the latest Allegro 4.4 tree (https://github.com/liballeg/allegro5/tree/4.4) from one year ago.

As long as we have the libs working on our end, then there's no real reason not to include them in the main branch. Cleaning up the repo clearly isn't happening, and that's outside of my realm of control. If we make a package that has ag4.4, with clean build files, clean and updated libs, and such; then it may as well be the new main, and it can go up into the repo whenever Gleeok or Saffith want to fix it, which if things progress as they have gone in the past, will be in a few months.

Realistically, we could fix that in a day or two, but they are the ones with repo access, and unless they want to add anyone else, they are stuck handling it. In the interim, I'd like to get us off all these ancient library versions so that maybe we can fix some of the hindrances that we're trying to fix in the worst ways possible. Hell, if we were to 'fix' one of these bugs without updating, then updating could instead introduce some quirk that we didn't expect, because we did something silly to work around a bug in software that is a decade out of date with the current tree.

4.4 also has quite a number of Mac-specific fixes, too. You should read the changelogs (http://liballeg.org/stabledocs/en/changes.html). Too bad that log doesn't cover 4.4.2 to 4.4.3. Could also fix the joystick issues on some Linux systems.

4.2 also refused to comply with being built on Linux, for Grayswandir: He couldn't compile ZC at all, using Allegro 4.2.x., for a long while. TBH, I don't recall if he ever solved that, or if he just went with 4.4.3.

DarkDragon
12-25-2016, 08:11 PM
Cleaning up the repo clearly isn't happening
I don't know why you say this -- it is going to happen, as soon as Gleeok and Saffith help me get the build tuned so that it works for them.

I am not opposed to switching to Allegro 4.4, but this is the wrong thread for that discussion. Moreover, if the switch happen, it will be over a series of small, thoroughly-tested and reviewed patches.

ZoriaRPG
12-25-2016, 08:42 PM
I don't know why you say this -- it is going to happen, as soon as Gleeok and Saffith help me get the build tuned so that it works for them.

I am not opposed to switching to Allegro 4.4, but this is the wrong thread for that discussion. Moreover, if the switch happen, it will be over a series of small, thoroughly-tested and reviewed patches.

Mostly, because all threads with posts on the subject are silent, and there has been no reply on either the plan, or the status.

I'm not sure how many incremental patches you'd want to do, other than one per library base, but we can discuss it later. I'm only asking you to test that build, because you are the only one with win10 that experiences these symptoms. I have win10, and I have never experienced anything other than the blue flicker bug, which this did fix. Primarily, my system is barely powerful enough to run win10 at all. |it doesn't have any fancy gfx hardware, and running the kinds of tests that prove anything just aren't feasible.

Knowing if you have the same problem with ag4.4 would indicate to us if this is meaningful, and if it requires further investigation, possibly including hardware purchases in the future.

Feel free to respond in the win20 thread though, as it'd be better than trailing off with this.

It would however, be good for Grayswandir to post about his experiences in working with compiling the 2.50.3 sources in Linux here, when he has time.

Grayswandir
12-26-2016, 01:55 AM
I don't know why you say this -- it is going to happen, as soon as Gleeok and Saffith help me get the build tuned so that it works for them.
Well, from my point of view, the very first thing you'd want to do to get the repo ready is to rename master into some other branch and get the current 2.50.x branch as master. Since that should take all of 5 minutes ... I'm not really sure what exactly you guys are doing.


Anyway, as for building on linux - the only problem I had was the sound only working with oss, which I'm pretty sure I've narrowed down to how allegro was built. Since we're not interested in allegro 4.4 right now, and I won't be able to get ZC's frakenstein version of 4.2 to compile without tens of hours of work, I don't really have much more to contribute to the discussion. Take a look at my makefile if you want. It's considerably shorter, and halfway decently commented.

(The actual changes to ZC making it compatible with 4.4 amounted to around 15 lines of code. And that was all undoing the changes that somebody decided to hack into ZC's allegro because having threadsafe file loading is vitally important. :confused_white:)

DarkDragon
12-26-2016, 02:04 AM
Well, from my point of view, the very first thing you'd want to do to get the repo ready is to rename master into some other branch and get the current 2.50.x branch as master. Since that should take all of 5 minutes ... I'm not really sure what exactly you guys are doing.

It's not branch 2.50.x that will be made master, it's branch cmake, and I'm not going to do this until I hear something from the other developers (and likely help them sort out how to make CMake correct configure the build on their system). What's the point in making 2.50.x the temporary master for a couple of days?

Grayswandir
12-26-2016, 02:26 AM
I wasn't saying you should. I was just pointing out that, as far as information I have, that's where we're at. Since fixing it would take 5 minutes, my best guesses are that either everybody is being incredibly lazy, or y'all decided to do something different and didn't bother telling us about it.

Gleeok
12-26-2016, 06:49 AM
This is somewhat a conglomeration of different topics.

Sorry guys; I'm a little unsure about the repo status as well. Keep in mind that 'master' is a few years of random commits - this represents the shardstorm repo as well. Most of these are from Saffith and I don't know what he wants to keep and throw away. I know that I want to keep all my changes, though the most I've done with ZC this last year is to basically get it all open sourced, and I'm not too sure about what's going on with it on the source code level: The files between the trunk and 2.50 can vary wildly, and I'm skeptical that this won't introduce really stupid (and potentially nasty) bugs. Testing will be required, and after 2.50.4 I think we should bump the major version.

I think I might feel better about merging files into 'cmake 2.50.x' one at a time. I've never done such a large "code squish" before, and certainly not one with multiple devs that represent both such a large time frame and also with an interestingly complex codebase that users count on to be stable at the same time. My subversion skills are also very basic as well, which I think is normally a good thing not having to lean on tools too much, but not so much here. To put it another way, my git skills are simply terrible.

Instead of CMake I'd prefer to migrate over my custom build from the trunk since it eliminates minutes (over 400% faster) off of the compile times and binary sizes, but I can download CMake and test it anyway.



I wasn't saying you should. I was just pointing out that, as far as information I have, that's where we're at. Since fixing it would take 5 minutes, my best guesses are that either everybody is being incredibly lazy, or y'all decided to do something different and didn't bother telling us about it.

We definitely will not be accepting any pull requests until everyone gets settled anyway so what's the difference?



[edit]
Downloading now...

1)Okay, so branch 'cmake' is definitely the WIP 2.50.x->master? So that's the one I should start dumping things into, right?

2)Can we just swap that one with master once the minor issues get sorted out, then worry about the rest of it afterward, or does anything else need to be done first?

3)2.50.x should be kept for 2.50.3 and short-term only minor bugfixes then, and we will accept only bugfixes for this branch then; is this also correct?


[edit2]
If we have people maintaining project files for different builds can we just have cmake as a 'backup' for everyone else?


..The holidays are getting to me. I'll have to start this project tomorrow. My brain is turning into mush.

ZoriaRPG
12-26-2016, 10:52 AM
Well, from my point of view, the very first thing you'd want to do to get the repo ready is to rename master into some other branch and get the current 2.50.x branch as master. Since that should take all of 5 minutes ... I'm not really sure what exactly you guys are doing.


Anyway, as for building on linux - the only problem I had was the sound only working with oss, which I'm pretty sure I've narrowed down to how allegro was built. Since we're not interested in allegro 4.4 right now, and I won't be able to get ZC's frakenstein version of 4.2 to compile without tens of hours of work, I don't really have much more to contribute to the discussion. Take a look at my makefile if you want. It's considerably shorter, and halfway decently commented.

(The actual changes to ZC making it compatible with 4.4 amounted to around 15 lines of code. And that was all undoing the changes that somebody decided to hack into ZC's allegro because having threadsafe file loading is vitally important. :confused_white:)

Oh, the threadsafe file loading was likely an attempt to prevent buggering the save file. I think that is separately resolved by preventing multiple instances as a runtime option, as that fix didn't work (?).

Mates, IDK what is happening. When Saffith said he wanted to make 2.50.x 'master', because he wanted to toss out the refactoring, and Gleeok said that'd be fine, we've all been acting under the presumption that this was finalized. That's why you can't let weeks pass when deciding these things, and then jump in and change things without public discussion and announcements of the plan.

We've all spent considerable time working on this mess, and remerging the changes is a genuine pain.

Make something main that isn't going to change. I suggest 2.50.x, stable. Make something the next dev branch. Set them in the repo, and we'll work from there, but please stop changing the plan, and doing things without discussing them in threads; so that we're all on the same page.

I'm going to again ask that the stable version slated as the next release is kept as master. That way, it's sane, and anyone who wants to build from it knows what is what. Making the development branch 'main' is just downright confusing to everyone, and it's very rarely done that way.

We can probably fix our changes in one or two days, but it's still a waste of time.

Also, is the CMake branch going to retain the MinGW/MSYS essentials? I don't particularly want to shift to CMake, especially as the way I've things configured now, it takes me all of two seconds to shift lib stuff out, and I can do simultaneous builds using the old, and the new libs without changing any paths or includes. I could use separate makefiles, I suppose, but this way I only need to decide if I use MSYS or cmd.exe to do the build. (MSYS builds on the old libs, cmd.exe with MinGW32-make does ag4.4.)

DarkDragon
12-26-2016, 12:35 PM
This is somewhat a conglomeration of different topics.

Sorry guys; I'm a little unsure about the repo status as well. Keep in mind that 'master' is a few years of random commits - this represents the shardstorm repo as well. Most of these are from Saffith and I don't know what he wants to keep and throw away. I know that I want to keep all my changes, though the most I've done with ZC this last year is to basically get it all open sourced, and I'm not too sure about what's going on with it on the source code level: The files between the trunk and 2.50 can vary wildly, and I'm skeptical that this won't introduce really stupid (and potentially nasty) bugs. Testing will be required, and after 2.50.4 I think we should bump the major version.

I think I might feel better about merging files into 'cmake 2.50.x' one at a time. I've never done such a large "code squish" before, and certainly not one with multiple devs that represent both such a large time frame and also with an interestingly complex codebase that users count on to be stable at the same time. My subversion skills are also very basic as well, which I think is normally a good thing not having to lean on tools too much, but not so much here. To put it another way, my git skills are simply terrible.

Instead of CMake I'd prefer to migrate over my custom build from the trunk since it eliminates minutes (over 400% faster) off of the compile times and binary sizes, but I can download CMake and test it anyway.





We definitely will not be accepting any pull requests until everyone gets settled anyway so what's the difference?



[edit]
Downloading now...

1)Okay, so branch 'cmake' is definitely the WIP 2.50.x->master? So that's the one I should start dumping things into, right?

2)Can we just swap that one with master once the minor issues get sorted out, then worry about the rest of it afterward, or does anything else need to be done first?

3)2.50.x should be kept for 2.50.3 and short-term only minor bugfixes then, and we will accept only bugfixes for this branch then; is this also correct?


[edit2]
If we have people maintaining project files for different builds can we just have cmake as a 'backup' for everyone else?


..The holidays are getting to me. I'll have to start this project tomorrow. My brain is turning into mush.

Let's do this: we will make the cmake branch (containing the 2.50.x changes) the master, and then we can look together at the changes you've made to the current master and merge them in one at a time, if they still make sense. Saffith was unhappy with some of the changes in the current master branch, but we can discuss with him and pull out the good bits.

I don't know if you've used CMake before, but it's basically a makefile for makefiles. You hit a button and it generated the MSVC 2010 project file for you, the MSVC 2016 project file for me, the Linux Makefile for Saffith and ZoriaRPG, etc. That way you do not have parallel but different builds set up by different developers for each platform, and you do not have to worry (as much) about one of the builds becoming out of sync with all of the others. If you want to add or remove a .cpp file from ZQuest, for example, you make the change in one place, in the CMakeLists.txt, and it automatically modifies the MSVC 2010 project file, 2016 project file, the Linux Makefile, etc.

CMake also makes it easy for new developers to download the source code and build ZC, as it's an extremely common and standard tool for multi-platform projects.

There should be no problem getting CMake to configure the MSVC project to speed up compilation (presumably, by using precompiled headers?). I will help you with this, once the basic compilation is working.

EDIT: And if you're getting errors, feel free to ping me on Skype (id: evouga) and we can sort them out together. (That also goes for you, Saffith).

DarkDragon
12-26-2016, 12:44 PM
Mates, IDK what is happening. When Saffith said he wanted to make 2.50.x 'master', because he wanted to toss out the refactoring, and Gleeok said that'd be fine, we've all been acting under the presumption that this was finalized. That's why you can't let weeks pass when deciding these things, and then jump in and change things without public discussion and announcements of the plan.

We've all spent considerable time working on this mess, and remerging the changes is a genuine pain.

Make something main that isn't going to change. I suggest 2.50.x, stable. Make something the next dev branch. Set them in the repo, and we'll work from there, but please stop changing the plan, and doing things without discussing them in threads; so that we're all on the same page.

I'm going to again ask that the stable version slated as the next release is kept as master. That way, it's sane, and anyone who wants to build from it knows what is what. Making the development branch 'main' is just downright confusing to everyone, and it's very rarely done that way.

We can probably fix our changes in one or two days, but it's still a waste of time.


Easy there. You can't complain simultaneously about 1) lack of decisive action and 2) lack of extended discussion. The discussion is happening right here and the plan is being made right here. Once Gleeok and Saffith and I are on the same page, you will have your reorganized repository. The repository has been in its current state for almost a year, another week or so won't hurt, especially (as you yourself point out) there needs to be public discussion before wildly rearranging things around. Patientez.


Also, is the CMake branch going to retain the MinGW/MSYS essentials? I don't particularly want to shift to CMake, especially as the way I've things configured now, it takes me all of two seconds to shift lib stuff out, and I can do simultaneous builds using the old, and the new libs without changing any paths or includes. I could use separate makefiles, I suppose, but this way I only need to decide if I use MSYS or cmd.exe to do the build. (MSYS builds on the old libs, cmd.exe with MinGW32-make does ag4.4.)
It will, if you help me configure it ;)
As for switching to CMake, any alternative that is platform-specific (and a single *nix-style Makefile is exactly that) is a non-starter. I'm 95% confident that CMake can configure your Makefile to do whatever it is you want to do, i.e. support two different versions of Allegro (though I'm hoping that in short order we will all simply switch to 4.4, assuming that solves more problems than it introduces). Yes, switching to CMake is a slight pain, but in the words of Spock, "the needs of the many..."

Gleeok
12-26-2016, 08:06 PM
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.

DarkDragon: The reason I never use cmake is because it never works right. It's always complained about missing files or whatever else. I'll give it a go, though I don't mind maintaining a project file.

DarkDragon
12-26-2016, 08:14 PM
@ZoriaRPG (http://www.armageddongames.net/member.php?u=42228) - 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.

Yes, exactly.


@DarkDragon (http://www.armageddongames.net/member.php?u=1) : The reason I never use cmake is because it never works right. It's always complained about missing files or whatever else. I'll give it a go, though I don't mind maintaining a project file.

It can be tricky to configure the CMakeLists file at first but I will help get it to work. Let me know what errors it gives you

Gleeok
12-26-2016, 08:58 PM
This is going well: "#error platform not supported"

Haven't even got to run cmake yet.

DarkDragon
12-26-2016, 09:04 PM
What did you run that gave this error?

You should run CMake before doing anything else. Download from https://cmake.org/download/ and run the GUI. It will ask for a folder containing the source, and a folder where to put the build files. Select the root folder for the former and ./build for the latter. Then hit "generate." If there are no errors, it should create for you a Visual Studio project file that you can open inside of ./build.

Gleeok
12-26-2016, 09:20 PM
CMAKE is still downloading. :x ..My internet is crap today for some reason...

In the meantime, ZC compiles fine with only a few minor things to fix up.
Now on to ZQuest. (Being able to compile ZC without cmake is also a good idea I think, so I'm doing that as well then build with cmake as well.)

DarkDragon
12-26-2016, 09:23 PM
What's the point?

You use CMake once, to generate the project file. It creates a project file that will work on your system, with your MSVC compiler. Then you use MSVC to edit the source/build the code.

You could keep a random second MSVC project lying around, but that is just begging for your build to become out of sync with the repository once somebody adds new files or changes settings (like external libraries) without any benefit...

Gleeok
12-26-2016, 10:13 PM
With CMAKE: Every file gives this error: fatal error C1083: Cannot open include file: 'stdint.h':

If I add it to a path I get many more errors... This was the same problem with boost. I forgot how I fixed it.... I'll need to check the log.


[edit] Aha! The problem is that allegro already defines these (in a bad way). ....crap.

DarkDragon
12-26-2016, 10:23 PM
You have MSVC 2008, right? I think I know the problem. Can you try re-generating the project and rebuilding using the latest commit?

Grayswandir
12-26-2016, 10:44 PM
@ZoriaRPG (http://www.armageddongames.net/member.php?u=42228) - 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.

Gleeok
12-26-2016, 11:01 PM
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





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.

DarkDragon
12-26-2016, 11:15 PM
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?

Gleeok
12-26-2016, 11:27 PM
Oh, I was just copypasta there. It's _snprintf for some reason.

Gleeok
12-26-2016, 11:43 PM
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.

DarkDragon
12-27-2016, 12:15 AM
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.

DarkDragon
12-27-2016, 12:26 AM
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.

Gleeok
12-27-2016, 01:04 AM
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.)



:( 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.

DarkDragon
12-27-2016, 01:14 AM
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 :-/

Gleeok
12-27-2016, 05:09 AM
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...

Gleeok
12-27-2016, 05:26 AM
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
12-27-2016, 06:16 AM
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
12-27-2016, 06:17 AM
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
12-27-2016, 07:06 AM
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
12-27-2016, 07:34 AM
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
12-27-2016, 01:57 PM
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
12-27-2016, 02:52 PM
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
12-27-2016, 02:53 PM
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
12-27-2016, 03:10 PM
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
12-27-2016, 10:07 PM
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).

DarkDragon
12-27-2016, 10:14 PM
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
12-28-2016, 01:47 AM
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
12-28-2016, 02:30 AM
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
12-28-2016, 03:00 AM
I just did. Sorry for the delay.

DarkDragon
12-28-2016, 05:18 AM
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
12-28-2016, 06:34 AM
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 )

Grayswandir
12-28-2016, 11:23 AM
I don't know if anyone has built romview in years.
I've got it building just fine?

DarkDragon
12-28-2016, 01:52 PM
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
12-28-2016, 01:54 PM
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.