Editor and Engine: Make it easier to use the project prerequisites (SDL, Ogg, etc)

[KeyserSoSay0]

Right now you have to edit the property pages in VS to set up the paths to the dependencies like SDL and Ogg. You also have to do it for both the Engine and the Editor solutions. Wouldn't it be easier to just have a pre-set relative path to the dependencies though? Especially since there's already a zip file with the pre-built dependencies in it. Then the instructions become a much simpler "just unzip this file into the base ags directory" or something like that.

You would lose the ability to point to some other SDL directory that you already have setup, but I would guess that almost everyone just grabs the prebuilt dependencies anyways? And in theory you could still point it to a different directory by using symlinks if you really wanted to.

Personally, I had never used the property pages before and it was weirdly difficult to figure out for VS2022 based on the Microsoft docs that are linked.

[ivan-mogilko]

Hmm, I'd like to clarify: you do not have to edit property pages for both solutions, you have to define user macros with paths once per a platform type (x32, x64), they will be used by all related projects that reference these.

Personally I build dependencies myself, and in rare cases switch between different versions when I need to test possible regressions in the library. Can't say for others though.

[ivan-mogilko]

I think that it's possible to support both options at once.
The *.props files define a colon-separated list of paths for included headers and libs, and these may have both a path which references user macro, and a predefined relative location. One thing that I do not remember by heart is what does MSVS do when it meets an undefined user macro, is that treated as error or treated as path that does not exist and ignored?

[ericoporto]

I use environment variables set in system once per lifetime. Can just make a bat script that sets some default of those maybe? (Using setx idk) just put the script at root of vs dependencies and run and done.

[KeyserSoSay0]

Hmm, so it looks like setting a default would be as simple as just putting some default relative paths in the .props files. Then the setup instructions could just be like "unzip WinDevDependenciesVS.zip into ags/WinDevDependenciesVS". If anyone wants to change the paths later they can still easily do that by editing the .props files.

BUT it looks like environment variables don't override the .props files. So anyone who has already set their environment variables would sync up and suddenly everything would be broken for them.

In VS2022 at least, when an include directory doesn't exist it just ignores it. So I suppose we could do something like rename the values in the .props files to things like AGS_SDL_INCLUDE_PROPS and then the include directories could include both of them "$(AGS_SDL_INCLUDE);$(AGS_SDL_INCLUDE_PROPS);...". That way anyone who has AGS_SDL_INCLUDE set in their env variables wouldn't have any issues since they probably wouldn't have that WinDevDependenciesVS directory and anyone who is just starting out could just unzip to that directory since it would be the default set in AGS_SDL_INCLUDE_PROPS.

And then I guess anyone that set the values in their .props files would get merge conflicts when they synced up, and that would probably be fairly easy to figure out.

[ivan-mogilko]

I'm not completely certain, but I've got a feeling that there's some misunderstanding about .props files and my proposal above.

.props files are not, and must not be edited at will in a personal fork. They are part of the solution, and part of the repository, and have to stay synced with central remote repository.

It's true that environment variables do not override .props files, they are referenced by .props files. But values of env variables are not part of .props file and so not part of the repository. Nothing is going to break if we add additional relative directories into .props files, regardless of whether user have set these variables in their system or not.

Actually, some of the .props files already have alternate directories along with the ones defined by env variables. These are added for the CI building, but ignored if such dirs are missing on user's system.

[ericoporto]

Just to be clear, the individual settings is because most of the time one is building their dependencies from sources to figure why something broke, so you set your environment variables to point to that (mostly SDL2 and SDL2_Sound). The idea of the ready built vs dependencies is to make it easier to kickstart a dev environment in a clean PC. Note that we do have to built these in the CI too - which uses a Windows docker + env variables to set things.

Another thing to pay attention is that the way the paths are set are backwards compatible - at some point x64 builds weren't supported and so the dependencies being x64 didn't exist. When they were added they were done in a way that switching between branches of ags before they existed didn't brake the dev environment. See #1870 .

So I wouldn't change these in a rush as I do think it's pretty clear how things have to be set in environment variables.

[KeyserSoSay0]

Ah ok that all makes sense. Now that I understand all of that, I think the issue is really just that the documentation is a bit confusing (at least to me). Here's the relevant bit from the windows setup readme:

"In order to direct Studio to necessary libraries and their headers setup following enviroment variables in your system by creating user macros in the Property Pages:

AGS_SDL_INCLUDE - pointing to..."

To me, that seems like it's saying that you should use the .props files since those are what are described in that "creating user macros" link.

I think if it just said "In order to direct Visual Studio to the necessary libraries and their headers, setup the following environment variables in your system:" then I would have never touched the property sheets and been WAY less confused.