Updated Project Settings to be Project Relative Opposed to Solution Relative

[CEbbinghaus]

No description provided.

[CEbbinghaus]

@richard-stern this should probably still be merged for the sake of any person wanting to use this at any point in future. It just fixes a very basic issue which ended up causing problems when students tried to rename projects.

[terrehbyte]

iirc, this project is no longer being maintained per @samcsss. It does look as though @DrMikeCooper has been doing some maintenance updates to support content that still depends on this, so he might be able to review these changes.

I don't make use of bootstrap in my delivery of the course, so I don't feel like I can comment on this very well.

That said, I generally find solution-relative dependencies are ideal unless doing something like integrating an additional dependency like Ink for a specific project. Keeping the dependency local to project seems appropriate in that case. Happy to defer to others though on this, since I don't use bootstrap.

[CEbbinghaus]

That said, I generally find solution-relative dependencies are ideal unless doing something like integrating an additional dependency like Ink for a specific project.

Solution vs Project relative dependencies wasn't the big problem. While in my opinion, it was a lot more convenient with them relative to the project so I could shuffle around projects and even copy them to other solutions. However, the big change that impacted a lot was the moving of the libraries to 64Bit rather than x64 since the .gitignore Ignores those:

aieBootstrap/.gitignore

Lines 17 to 18 in ee2ed86

	x64/
	x86/

Often times students would rename their projects to whatever they were working on "AsteroidGame" which would break the Solution's relative dependencies (which they would have to update). But more importantly, while it worked locally checking these changes into Version Control would cause the libraries to be ignored. So when they tried to work on the project anywhere else or after the PC had been wiped it would break and they would have to grab the original libraries from the git history.

While I don't expect this Repo to still see as widespread use as it used to the changes I made helped me personally work with the solution by being able to rename projects according to their purpose without the headache of having to reconfigure Visual Studio or worry about Version Control removing the libraries I needed.

[terrehbyte]

However, the big change that impacted a lot was the moving of the libraries to 64Bit rather than x64 since the .gitignore Ignores those:

Gotcha, understood. I tend to solve this by creating an exception to this rule in the dependencies folder. While we normally ignore x64 to exclude build artifacts from version control, we may want to consider them for our dependencies. I did this for AIE Seattle's raygame starter project, which also pulls in C/C++ dependencies:

https://github.com/AIE-Seattle-Prog/raygame/blob/6295d3a585a90e3a23f26c079cb9ee6cdc9b0c23/thirdparty/.gitignore#L1-L5

I'd imagine that'd be a less disruptive solution that also more uniformly solves the problem.

Retaining the use of x86 and x64 also allows me to make use of the $(PlatformShortName) VS macro, which also reduces the complexity of configuring the library directories to a single directive for all platforms, 32 or 64 bit on Windows:

https://github.com/AIE-Seattle-Prog/raygame/blob/6295d3a585a90e3a23f26c079cb9ee6cdc9b0c23/raygame/raygame.vcxproj#L82-L87

...

While I don't expect this Repo to still see as widespread use as it used to the changes I made helped me personally work with the solution by being able to rename projects according to their purpose without the headache of having to reconfigure Visual Studio or worry about Version Control removing the libraries I needed.

I appreciate contributions from students/graduates on AIE course materials since they're by no means perfect, so thanks for engaging, nonetheless. 😄

[CEbbinghaus]

I agree that adding an exception to the x64 gitgnore entry is probably a good idea and a better solution. Should i ammend to my commits adding those changes?

[terrehbyte]

Yeah, go ahead and add those changes to your PR as you see fit.

Note that you're currently targeting the v2019beta branch which isn't actively being maintained. If you've got the time, it'd be more likely to be used if you targeted the main branch instead.

[CEbbinghaus]

The beta branch does have 8 commits that main does not. Ideally they would be merged before I Retarget the changes