Banderi / Ozymandias

An open source re-implementation of Pharaoh (1999) in the Julius/Augustus engine
GNU Affero General Public License v3.0
109 stars 10 forks source link

Building on Windows SDL2_IMAGE issue #9

Closed SandroWissmann closed 2 years ago

SandroWissmann commented 2 years ago

Hi again.

I try to compile now also under windows vm to see how far it works there.

However when I run

cmake .. -G "MinGW Makefiles"

I get this output:

` Screenshot_20220918_221241

`

So something here complains about SDL_image. However I did not touch the SDL_image folder.

I think maybe the issue here is that I use the latest SDL2 and SLD2 mixer libraries. However I could not find older ones with MinGW. Like it is mentioned here: https://github.com/bvschaik/julius/wiki/Building-for-Windows

So I have

SDL2_mixer-2.62 SDL2-2.24.0

Is that to new maybe? Do i need the 2.0x versions?

crudelios commented 2 years ago

You need the SDL_image for Ozymandias, unlike julius and Augustus where you don't need it. Did you get it?

SandroWissmann commented 2 years ago

I was not sure if i have to download it separetly because there is already a tar.gz file in the SDL_image folder. So I just download it like the others and thats it?

crudelios commented 2 years ago

I think you need to extract the file somewhere then provide its location like you do for sdl and sdl_mixer.

SandroWissmann commented 2 years ago

I downloaded the mingw SDL_Image and added this like the other things for SDL2 like this:

Screenshot_20220919_160925

Still no luck. Still get this error:

Screenshot_20220919_160856

crudelios commented 2 years ago

Try adding it inside the SDL2 folder.

However, I think the cmake/FindSDL2_image.cmake file is incomplete as it does not search in the ext folder like SDL2 and SDL2_mixer do.

In that case, you'll need to provide the -DCMAKE_PREFIX_PATH=<path to the sdl2_image folder>. That may or may not work.

SandroWissmann commented 2 years ago

tried it with abolutes path like you suggest but also no luck:

Screenshot_20220919_184648

All very strange on linux im pretty sure I did not even install sdl_image extra (just install sdl2 and mixer via command line).

Mayb @Banderi knows what he did to set it up (Would be maybe a really good idea to fix instructions how to build on windows)

Banderi commented 2 years ago

Ah yes, this was another mess that I threw together to make it compile on my end; I couldn't figure out how to set up SDL2 on my end way back when, and did not dare touch the cmakelists.txt, so...

I forget exactly how I set it up, I'll have to check my CLion files...

SandroWissmann commented 2 years ago

Mabe its just a version issue with sld and sld_mixer. Maybe check which ones you have in your ext folder.

I also did not know whats with the tar.gz file in the Sdl_image folder.

SandroWissmann commented 2 years ago

Just to add. I checked what I have installed under manjaro:

sdl2 2.24.0-1 sdl2_mixer 2.6.2-1 sdl2_image 26.2-1

So that atleast confirms we somehow have to install sd2_image on windows.

So there is maybe really only something wrong with this build script

SandroWissmann commented 2 years ago

I also tried to add sld2_image like this to the main cmake:

find_package(SDL2_image REQUIRED)

but no luck.

Also with the main CMake I would expect that we have to put all the SDL2 stuff in one folder like this:

Screenshot_20220919_210522

Then I would expect that somehow FindSDL2_image.cmake would work but looks like still something missing.

Unfortunately my CMake knowledge is quite limited..

crudelios commented 2 years ago

Try adding

GET_SDL_EXT_DIR(SDL_IMAGE_EXT_DIR "image")

To the first line of your FindSDL_image.cmake file.

Edit: actually, forget that. The file should be similar to FindSDL_mixer.cmake to work and it isn't.

Short of fixing the cmake file it won't properly work for Windows!

SandroWissmann commented 2 years ago

Ok I can try it tomorrow. But ypu say I does not work?

Banderi commented 2 years ago

Yeah, it's a huge mess... This is actually of the biggest reasons I want to start fresh, because SDL2 is a huge pain in the butt and I want to have a clean way to build it with clear instructions. I think the way I did it is I manually added the absolute paths to the CLion project, as you have done, and I think that translates into the -DCMAKE_PREFIX_PATH flags as mentioned above but I need to check to be sure.

SandroWissmann commented 2 years ago

If you look in the above post somehow it was not working with -DCMAKE_PREFIX_PATH. Maybe I still did something wrong.

I remember when I did https://github.com/SandroWissmann/Bricks it was also a huge pain for me just figuring out how to add SDL2 and SDL2_mixer in CMake. But now we have image. Maybe we can also ask for help in the repo from SDL2_image...

But I think we can figure it out.

What baffels me is that on linux I just needed to issue install comand for the SDL2 stuff via command line and then the CMAKE files somehow could find all the libraries with not issues (Not even copy SDL2 by hand to ext/folder)

crudelios commented 2 years ago

Yes, cmake searches the OS library/ include paths on linux automatically, making things easier.

On windows you have no such specific paths, meaning you have to set things manually.

I don't have time now, but if you adapt the mixer cmake for image (just change the variable names!), you should get it to work

SandroWissmann commented 2 years ago

Ok I will try it out tonight and open a branch for it. even if it is not working you can maybe take a look at it to suggest more things we can try.

So i just rewrite SDLImage cmake to be the same as mixer one and mayber add these Image includes in the main file.

Banderi commented 2 years ago

Just checked my project, here's what I did: -DCMAKE_PREFIX_PATH=LIB\64 -DSYSTEM_LIBS=false It seems I already committed all the files as well (because I knew this was gonna happen so I wanted to have all the working lib files ready), so you should be able to try them out without downloading anything separate.

SandroWissmann commented 2 years ago

I tried to fix the cmake like @crudelios suggested but we still get an error.

See this faulty pull request: https://github.com/Banderi/Ozymandias/pull/11

Maybe I just forgot something here?

SandroWissmann commented 2 years ago

I also tried with the arguments @Banderi suggets on the original master branch but also no luck.

Screenshot_20220920_170656

This must be really something very stupid we are misssing here...

Banderi commented 2 years ago

Keep in mind the LIB folder is in the root directory, so I think if you're calling cmake from inside the build folder, it's not gonna find it like that. Maybe you need ../LIB/64 in your case?

EDIT: nevermind, that's what the .. is for after all. I just tested the commands on my end and it found the files, but complained about the version as well. It actually generates correctly, but of course didn't compile any executable yet. image

SandroWissmann commented 2 years ago

Looks like you did exactly the same as me but somehow not get this complain...

Do you have any files in the SDL2 folder?

Banderi commented 2 years ago

What MinGW version are you using? I'm using MinGW 9.0.0 with GCC 11.2.0. I used to use 6.00 with GCC 8.1.0 but it stopped working a while back (maybe because of the same issues I was having with C++14? I forget)

SandroWissmann commented 2 years ago

GCCis 12.2.0. MinGW im not sure how I can check it but I think its the latest.

Banderi commented 2 years ago

Just quickly tested with the latest one, GCC 12.2.0/minGW 11.0.0 and it seemed to generate and compile exactly the same... maybe a problem with CMake?

Also, are you using the w64 version of MinGW or the 32 bit one?

crudelios commented 2 years ago

There seems to be progress though @SandroWissmann: at first it didn't detect the header files, and now it seems to detect them and it's only missing the library file.

SandroWissmann commented 2 years ago

I used MinGW64 bit. I thought its right because Windows 10 is 64 bit.

CMake is version 3.24.2

Banderi commented 2 years ago

Yeah, was just to make sure; I included the 32 bit files because I had them, but I did not get them to work, and my system is 64 bit as well so had no reason for it.

My CMake is 3.24.0-rc3, I doubt the minor difference should be the issue... so something else is the culprit.

SandroWissmann commented 2 years ago

Do you have anything in your ext/SDL2 folder and also ext/SDL_Image ?

Banderi commented 2 years ago

Nothing, apart from an old tar file I had of the library which apparently I committed along. I downloaded the repo fresh to test if I had anything locally that made it compile, but it worked all the same. The only thing that are currently needed in ext (at least for the generation) are expat and tinyfiledialogs.

SandroWissmann commented 2 years ago

I got it to work now with the ext/SDL2 folder in the merge request @crudelios fixed. No I just need to find out why make does not work I think its a slghtly different command on linux

SandroWissmann commented 2 years ago

actually now both ways work after delete clean the build folder:

Either with

cmake -DCMAKE_PREFIX_PATH=LIB64 -DYSTEM_LIBS=false .. -G "MinGW Makefiles"

or just cmake .. -G "MinGW Makefiles"

with the fixed branch. if you supply in ext/SDL2 all SDL2 Mixer and Image.

Banderi commented 2 years ago

Aha! Classic CMake corrupted/partial buildfiles being a nuisance.....

SandroWissmann commented 2 years ago

Oh yes. Even me working full time C++. I still fell for it from time to time. Its generally if something is unexplained this can be the solution. I thought between tries i actually deleted the build folder.