Building on Mac and Linux

[DarkDragon]

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]

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]

Ok, thanks.

Do either of you still use MINGW on Windows?

[Gleeok]

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? (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]

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.

[DarkDragon]

Whoops, posted this in the wrong forum. Moved to ZC Development.

[Grayswandir]

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]

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]

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]

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.