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?
Printable View
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?
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:
should beCode: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
Code: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.
Ok, thanks.
Do either of you still use MINGW on Windows?
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.
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/Z...sic/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.
Whoops, posted this in the wrong forum. Moved to ZC Development.
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.
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.
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.
What conversion is needed? 4.4 API is not backwards compatible with 4.2?
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.
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...egro_4.4.3.zip
This relates to these log entries for ag4.4:
The latter of these two issues was a very annoying bug in ZC/ZQuest, and the former helps fix some graphic badness.Code: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 makefile should be in there, I build Allegro following the instructions here, here, and here using the latest Allegro 4.4 tree 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. 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.
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.Quote:
Cleaning up the repo clearly isn't happening
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.
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:)
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?Quote:
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.
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.
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.
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.)
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).
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.
It will, if you help me configure it ;)Quote:
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.)
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..."
@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.
Yes, exactly.
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 youQuote:
@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.
This is going well: "#error platform not supported"
Haven't even got to run cmake yet.
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.
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.)
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...
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.
You have MSVC 2008, right? I think I know the problem. Can you try re-generating the project and rebuilding using the latest commit?
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
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.
:( Let's get to the bottom of things then...Quote:
It's okay, nobody else knows what is going either.
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.
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.)
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
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.Quote:
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
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...