Editor and Engine: Make it easier to use the project prerequisites (SDL, Ogg, etc) about ags HOT 7 OPEN

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.

from ags.

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?

from ags.

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.

from ags.

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.

from ags.

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.

from ags.

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.

from ags.

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.

from ags.