Comments (7)
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.
Related Issues (20)
- Debugger: support step-over and step-out commands HOT 3
- Engine: Rendering graphical glitch HOT 9
- AGS 4: Script API: add "split options" for String.Split method HOT 6
- Deprecate 'function' keyword HOT 4
- Expand on_mouse_click callback parameters with click position
- Editor: having multiple project folders which names are different only in letter case breaks the item drag-n-drop HOT 1
- Editor: an option that disables panel dragging and un-docking
- Editor: restore document panes when resetting a layout
- Preprocessor gets infinite loop meeting a non-latin unicode char in script HOT 3
- Typos in DistanceBetween routine cause wrong calculation HOT 3
- Engine: Windows freezes on Alt+Tab for a specific player HOT 17
- Script API: add "startIndex" parameter to String.IndexOf HOT 26
- Editor: Ctrl+C / Ctrl+V key shortcuts do not work in GUI editor HOT 1
- Feat. req. Pre 2.5 version games support (DOS, 3.11) for Windows runtime engine HOT 1
- AGS 4: remove 16-bit game color depth HOT 2
- Editor: batch-resave all project rooms in the latest format HOT 1
- AGS 4: in Script API change default values of "caseSensitive" parameters to "true"
- [AGS 4.00.00.07] Sierra style template and Tumbleweed template don't work HOT 4
- Support rasterizing the Room viewport to a dynamic sprite HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ags.