OP2 Dev with VS Code with Makefiles!

[Angellus Mortis]

So first off, surprise, I am back. I have been loitering in the IRC for the past couple of weeks.

I do a lot of development now and I exclusive use VS Code for pretty much all of it. This includes Python, Javascript and Java. So naturally I set up VS Code to work with OP2 as well. To do that, I restructured the file structure of a "project" a bit and converted the Visual Studio Project file into a Makefile that NMake can understand and use from command line. You can check out the full details on the feature/vs-code branch on LevelTemplate-Blank-Comments.

Visual Studio Code is free, cross-platform and lightweight IDE made by Microsoft. It is sort of a spiritual successor to Sublime Text. Out of the box, it is mostly just a code editor, similar to Sublime Text or Notepad++, but VS Code has a vast library of extensions that adds various IDE features for numerous languages, including Java, Python, C++, C# and Javascript/Node.js. Using VS Code still requires Build Tools for Visual Studio, but does not require a full Visual Studio install. Also, as noted, VS Code is cross platform. This means once I (or someone else) works out doing the cross compiling allow you to build DLL files from Linux/Mac OS and OP2 still be able to run them, we can a full cross platform OP2 development solution!

[Vagabond]

Welcome back Angellus! You changed your avatar. I should probably get an avatar someday...

Some of the Linux users on here might appreciate having this available. I remember spending about 30 minutes in Visual Studio Code a couple of years ago, but have no real experience with it.

I was thinking we need to add OP2DLL and OP2Helper as submodules to all the level templates.

-Brett

[Angellus Mortis]

Hooman and I were chatting and unfortunately to get this to build on MacOS/Linux, we need MSVC. MinGW and Clang looks like they will not work as they do not link correctly and the .dll is unusable. I have not had much luck getting Build Tools for 2017 working on Linux yet, so no luck on that yet.

I was thinking we need to add OP2DLL and OP2Helper as submodules to all the level templates.

I would probably not recommend that. If each level template had same submodules then you would a lot of duplicated code.

I was thinking of setting up a repo just for dev documentation via Github wikis and possibly even setting up a "install script" inside of the repo to set up a dev environment. Similar to checking out the subversion repo.

[Vagabond]

By duplicated code, what do you mean? OP2Helper and Outpost2DLL would still link back to their original repository. The coder is going to want to reference these projects often when making a scenario, so having the source code available in the same solution they are working on seems helpful.

-Brett

[Angellus Mortis]

I mean if you have more than one level, you would have a copy of OP2DLL and OP2Helper in every repo. Submodules are great if you want to include a dependency and are not going to have it anywhere else or if you want to target a specific version of a dependency that changes a whole bunch.

Since the main OP2 SDK deps very rarely change, it would probably just be better to install them manually or via a script to automate it. Then you can have them in every project without the duplicated code.

[Hooman]

Thank you very much for this!

I had MSVC running on Linux under Wine, but didn't have a makefile to build projects with. I needed the makefile because although the MSVC compiler worked with Wine, the MSBuild system didn't, so I had no easy way to build projects from a project file. Typical compiler invocations had a lot of flags passed to the compiler, so it was an excessive pain to make manual calls to the compiler by hand.


The client side code duplication also used to bother me concerning Git submodules. I didn't like the idea of having a whole copy of the SDK in every level project folder.

Even worse, if you use an API both directly and indirectly, such as using Outpost2DLL directly, and another API, say OP2Helper, which also uses Outpost2DLL, then you can end up importing Outpost2DLL from two different levels, and have two copies of it in the same level project. Even more confusing, the two copies might be pinned to different versions.

Project
  - Outpost2DLL
  - OP2Helper
    - Outpost2DLL

I would like to avoid duplicate copies within a single parent project, and use a more flat dependency model.

Project
  - Outpost2DLL
  - OP2Helper

An alternative structure, is to have a parent master project that includes all the sub projects. This is basically how the SVN layout works.

MasterProject
  - API
    - Outpost2DLL
    - OP2Helper
    - HFL
  - Levels
    - Project 1
    - Project 2
    - Project 3
    - ...

That would be one way of keeping the structure flat. The downside though, is all projects are then pinned to the same version of the API, which is not necessarily correct. If I make updates to an API, I don't want to have to update everyone else's project that uses that API. Likely such projects would just get out of date, and might fail to compile with the newer API libraries.

Per project pinning of dependencies makes the most sense. I think it can still be done in a way that keeps it reasonably flat, while also isolating separate projects from API upgrades.

As for duplicating the API in each project, I think that's something you just have to live with if you want a solution that is actually correct, and supports different projects building against different API versions, which you really need when you have multiple authors, and not every author necessarily wants to share their source code. By trying to save disk space, you'd have a less correct solution.

These days, disk space is cheap and plentiful.

[leeor_net]

Hooman and I were chatting and unfortunately to get this to build on MacOS/Linux, we need MSVC. MinGW and Clang looks like they will not work as they do not link correctly and the .dll is unusable. I have not had much luck getting Build Tools for 2017 working on Linux yet, so no luck on that yet.

This should come as no surprise. MSVC's linker doesn't map memory or use the same name mangling techniques that any other compiler uses. I suppose with a DLL that shouldn't technically be an issue (dll exports and such) but we're dealing with software that's over 20 years old and expects things to be in specific places (e.g., using 'clever' tricks and undocumented assumptions about memory mapping and alignment).

Since the main OP2 SDK deps very rarely change, it would probably just be better to install them manually or via a script to automate it. Then you can have them in every project without the duplicated code.

Is this not the point of a submodule?

As for duplicating the API in each project, I think that's something you just have to live with if you want a solution that is actually correct, and supports different projects building against different API versions, which you really need when you have multiple authors, and not every author necessarily wants to share their source code. By trying to save disk space, you'd have a less correct solution.

These days, disk space is cheap and plentiful.

This. This right here.

[Angellus Mortis]

An alternative structure, is to have a parent master project that includes all the sub projects. This is basically how the SVN layout works.

MasterProject
  - API
    - Outpost2DLL
    - OP2Helper
    - HFL
  - Levels
    - Project 1
    - Project 2
    - Project 3
    - ...

This was the type of structure I was thinking of. If I have other levels in my project, I do not often build them. They are just there for references. I guess the concept of a project does vary from IDE to IDE though. I do not think you can add a "project" to Visual Studio without it being compiled.

As for duplicating the API in each project, I think that's something you just have to live with if you want a solution that is actually correct, and supports different projects building against different API versions, which you really need when you have multiple authors, and not every author necessarily wants to share their source code. By trying to save disk space, you'd have a less correct solution.

These days, disk space is cheap and plentiful.

This. This right here.

HDD space is plentiful (I have over 50TB raw in HDD), but SSD space is not always. I know space can get pretty tight on a Windows machine with 256GB SSD or smaller on your main drive and many portable devices come with small SSDs. I guess it largely comes down to everyone's personal preference and device setup. I tend to try to avoid submodules as they are not always the best thing to throw new developers into. I still have a number of co-workers who have trouble understanding submodules. :/

[Vagabond]

The Outpost2Dll repo is about 500-600KB in size. I don't think it matters too much from a hard drive perspective.

It is a good point that we want a simple way to program levels. Someone new to programming is going to have enough trouble without worrying about submodules, repositories, multiple copies of the same project on the computer, etc. It is probably good enough if we post a 'release' of a commented level template that is a simple zip of everything together. This can be updated to a new release when any of the base code changes.

SVN is nice in that you could link to different versions of the same project via tags on different portions of the same repository. It actually lends itself really well to Outpost 2 scenarios. It is pretty much exactly what Angellus is describing I think.

---

Hooman is right that it is weird if Outpost2Dll exists twice in the same project. The problem is you will want it to be available to OP2Helper in a standalone library form and available to the scenario. This is fairly easy to do with Visual Studio with the concepts of Solutions and Projects. I don't know how to get around having Outpost2Dll in 2 submodules in a scenario though. One from OP2Helper and 1 from the scenario itself. Hmmm.

---

Angellus, I look forward to see what you figure out / do in https://github.com/OutpostUniverse/LevelTemplate-Blank-Comments/pull/1.

-Brett

[leeor_net]

HDD space is plentiful (I have over 50TB raw in HDD), but SSD space is not always.

Can't argue this... but that's also why a setup using SSD's would have the operating system and critical software on the SSD while everything else would be on standard HDD's. At least that's how I do it.

I know space can get pretty tight on a Windows machine with 256GB SSD or smaller on your main drive and many portable devices come with small SSDs.

Also can't argue with this. At work we regularly deal with 'netbook' like laptops that use 32GB internal flash memory with no option to expand. This is absolutely baffling to me as 32GB is barely enough to run Windows with a decent virtual page file and maintain updates, etc. I have so many customers come through the door asking what they can do and my only answer is "Don't be so cheap when you buy a machine with larger storage options". Those machines are best left for much smaller Linux builds -- no idea why manufacturers insist on 32GB vs. 64. 64 is at least usable.

[/quote]I guess it largely comes down to everyone's personal preference and device setup. I tend to try to avoid submodules as they are not always the best thing to throw new developers into. I still have a number of co-workers who have trouble understanding submodules. :/[/quote]

Sounds like junior developers that need to spend a bit more time reading. Admittedly I only recently learned how sub-modules work but that was more a case of how to operate Git vs. how they actually work. The concept itself was very easy to understand.

On that note... I've noticed that more and more 'developers' are completely clueless when it comes to how computers actually work. But that's probably a topic for another thread.

[Hooman]

I don't really recommend the SVN layout, due to the maintenance concerns. When APIs get updated, I have no desire to go through each level and test if they still work with the API upgrade. Rather, I would only worry about upgrades if I was specifically working or doing maintenance on a particular project. With Git submodules, the versions are pinned until explicitly updated. This makes testing a natural part of the upgrade process, and means no failures by default if you don't upgrade.

I think it makes more sense for each project to have version pinned dependencies.


Of course the nesting structure within a project doesn't exclude the possibility of also creating a master project which includes everything. That might make for a good reference project.