MWEdit
- This topic has 225 replies, 2 voices, and was last updated 14 hours, 9 minutes ago by
.
-
Meson has some form of compatibility with CMake but I haven’t looked into it yet.
Yeah, that’s due to the libraries being 32-bit while the rest is 64-bit. You can use 32-bit code in 64-bit programs but it can have issues if one isn’t careful. It’s generally best to use the same architecture 🙂
I’m leaning towards ResIL myself as DevIL is no longer being maintained. Generally best to go with something with active development in my opinion 🙂
Haven’t heard back from the Meson devs or NimrodPSI yet so I may start working on a basic CMake script soon to see if that works before we start trying other stuff.
Edit:
Looks like C++23 has better Unicode support so we may want to update the standard (or https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html#prop_tgt:CXX_STANDARD) once we get things working under C++20.
Looking over the CMake reference manual again now…..
Okay, I just finished setting up a basic CMake script: https://github.com/Walrus-Tech/MWEdit/pull/35
Are you able to test it? I haven’t set up the CI yet for CMake, I’m looking into the command-line commands now.
It is based off the Meson branch as it needs the source changes. It’s nothing fancy and doesn’t add the extra CMake options that I would like to use such as PIE; Windows conditionals; or messages, this is simply to test things to see if CMake works where Meson failed.
Edit:
Still tweaking things. Had to set some more CMake settings in the CMake script. Looks like it’s going now. Will find out what happens in a few minutes.
Edit 2:
Still working through re-learning things. If the latest CI build fails, I’ll go back to it tomorrow.
Still crapping out on DevIL so it’s the project, not Meson. I’ll take a closer look at the provided project file when I get the opportunity to see if I can figure out why it works but will plan on decoupling the bundled version if nothing stands out
Once we get things working, we can decide on a final build system 🙂
No worries! Whenever you get things set up is fine 🙂
Figured the CI stuff out: they changed how you use CMake from the command-line since I last used it. So the CI has been updated 🙂
I think that’s a different issue. The bug looked to be an obscure parser bug that was occurring regularly but then disappeared randomly. Meson was complaining about not being able to run Ninja and to use Ninja instead before it even got to the build step.
Yep, we’d just need to update the build script to point to the end result and then set up building the libraries separately. Sadly, the BOSS build docs are incomplete in that regard (I never got around to updating them for CMake) but we should be able to borrow the general idea from other projects. I’ve been using LOOT as a reference point as I was deeply involved with it in the early days so a lot of the build setup closely resembles what BOSS uses
BOSS used a library subdirectory but I’m not sure if that’s still the best way to handle it. Definitely need to look around to see how others do it
Got the MFC stuff added to CMake locally. At least, I think it’s done. It’ll be in the next push. 🙂
Now to work on a plan for the image library.
Edit:
Build instructions are a little sparse and the DevIL directory tree is weird, which may complicate things. ResIL also lacks build instructions and the directory structure is better but still weird: it just removes a couple of folder levels but has stuff named
src-IL/srcetc when we use it withIL/. The installation script may fix that, though. Going to take a few days to read through everything and see if I can figure it out.Quite a few dependencies: https://github.com/DentonW/DevIL/blob/master/DevIL/Libraries.txt
Don’t see a similar list for ResIL but I do see bundled directories: https://sourceforge.net/p/resil/code/ci/master/tree/Input_Libs/
Not sure if that’s the same thing. They don’t cover all of the dependencies, though.
Edit 2:
CMake has a module to help link with DevIL but we’d still need to set things up first and build it. Other option is to set CMake to download and unpack the binaries on its own (assuming they’re provided, haven’t looked at the packages yet) and then use the module to link everything together. As we know, Windows is a bit more cumbersome for development than *nix setups 🙂
Ah, okay, and the lack of responses to this ResIL issue are a bit of a worry as well. Those input_Libs look good even they are all in C – seems the same with the DevIL sources.
Sounds good, go with including the DevIL code modules rather than compiled DLLs looks to be a better option, although a C++ version of everything would be a plus. 🙂
The link for sources is broken:
http://openil.sourceforge.net/libs/LibSrc.zip
There’s bound to be usable and more up-to-date C++ sources for all those somewhere, but where?
Been looking at whether to get VS or VSC for Morrowind – see:
https://stackoverflow.com/questions/30527522/what-are-the-differences-between-visual-studio-code-and-visual-studio
For the sheer size of Morrowind it has to be VS no? Are you running that on Windows Server?
Edit: Going with VS of course! MFC, SDK, MSVC and especially CLang use a fair bit of space – some way of leaving any of them out?VS with the usual SDKs (make sure you grab the C++20 runtime as that’s what we’re targeting right now but may switch to C++23 later) with the optional MFC package, along with Git so you don’t need to keep grabbing the tarballs and CMake (at least initially). From my investigating, MFC is the only optional Windows component in use. Visual Studio Code doesn’t provide the full development stack needed.
I would recommend using MSVC instead of clang as the current setup relies on MSVC built packages, which can’t link to clang binaries due to a different ABI. All this will change, of course, when we switch to a cross platform UI toolkit (and sort out the image library) and then you should be able to use whatever you want. 🙂
DevIL is provided in the repos over here on Linux but not ResIL so manual builds will be required for ResIL use on Linux. I’m leaning towards DevIL, at least initially, to make debugging easier if the files needed are in the download. Later on, after we get it working, we can look at switching to ResIL
Do these work: https://openil.sourceforge.net/download.php ?
Will also need to see if they can be acquired via the command line. If not, we’ll need to do some more thinking
Yep, the CI is running MSVC through CMake at the moment. Before the build script, it was using MSBuild. 🙂
Okay, here’s the download link for the 1.8.0 SDK: https://gigenet.dl.sourceforge.net/project/openil/DevIL%20Windows%20SDK/1.8.0/DevIL-Windows-SDK-1.8.0.zip
That’s a direct link and wget grabs it without issues so we should be able to plug that into the CI and have it grab it and unpack it for automated builds. It includes both the Unicode versions and non-Unicode versions, along with both 32-bit and 64-bit libraries. Not sure if we need Unicode or not, though. Locally, you’ll want to overwrite the DLLs and
.libfiles, and move the includes to the IL directory, with those versions until the scripts are fully updated. I have no idea if we need the export files or not. I’m also unsure if we need all of the DevIL libraries but we can figure that out after things are working. We may be able to drop the OpenGL support, will need to see what MWEdit does with the code. I wouldn’t think so. Hopefully the 64-bit versions of the libraries fix the issues we’re having. I checked the bundled project file and it doesn’t do anything special, the only real difference is that it’s 100% 32-bit without 64-bit code.We now have a 64-bit build of MWEdit. Swapping out the 32-bit version of DevIL did the trick. Now I just need to clean everything up and we can decide on a build system. The packaging script needs fixing: apparently, GitHub Actions preserves the directory structure during packaging so we have an unusable archive without moving the files around after download. Maybe it’s time to set up an install script? CMake supports WiX through CPack for MSI creation, along with RPMs and DEBs for Linux. Perhaps we can start with the provided options before looking at custom install scripts, depending on how difficult CPack is?
Leaning towards CMake. While Meson is definitely cleaner it lacks features and it’s a bit cumbersome to do more than the basics. That said, I’m definitely open to other opinions. 🙂
Probably worth doing a release after the packaging is sorted out as 64-bit support is a rather important change
Edit:
Just updated the threads with the latest news 🙂
We now have an installer in the MSI format: https://github.com/deathssoul/MWEdit/actions/runs/18903584084/artifacts/4403855739
If possible, could you do a test run and report back as to its behavior? I have no clue if it’s set up properly. 😛
I’ll put out a testing call on the other sites later. 🙂
Edit:
Posted to the other sites. Additionally, the CMake script is now cross-platform compliant even if MWEdit still builds only on Windows. Still need to add the options to build a static executable when cross-compiling. That’ll be a bit hairy as things stand right now so I’ll add that to the to-do list.
Edit 2:
Looks like I may need to pass the Unicode macro after all as it’s used in dl_base. Missed that earlier. Of note, the old VS project file doesn’t have Unicode set to on. Will wait to see what the test results come back as. Enabling Unicode may be a thing for 0.7.1
Edit 3:
New package: https://github.com/deathssoul/MWEdit/actions/runs/18935772066
Has some DevIL updates 🙂
There’s no Licence agreement, and it’s best to include a prompt to run the show at the final install step. There’s a folder called Config.Msi created in the C: directory. The bin and share folders look okay, as you know, the exe aborts because of the missing DLLs.
Also a choice of whether the user wants desktop shortcut and a folder created inStart Menu\Programs.As far as testing goes, we’ll want to check UpperLowerProper for Morrowind on Linux at some stage – any luck yet?
Crumpets. The license should be getting imported. I’ll have to take a closer look at the commands. I definitely have that option set but I may need to update the file format
What’s in the Config directory? That’s new.
Are the DLLs anywhere? May need to tweak the directory layout. What’s the directory structure look like? They’re definitely getting bundled into the file, sounds like they’re just not getting in the right spot. Where are the
.datfiles? They should be getting dumped to the same placeIs the option for a desktop shortcut not working, then? Will look into the Start Menu stuff. It’s possible I used the wrong options
Haven’t had to chance to look at it yet but I’m not sure Linux can run Windows style Batch scripts.
Edit:
Provided some compatibility information in the other thread. May not be too hard to update it for Linux 🙂
Removed the installer from the other sites for now as it doesn’t sound like it’s working properly
Thanks. That’s probably due to me using the DATA file type. The install system on CMake is poorly documented for anything other than *nix, sadly. I may be able to force them into the same directory, will look into it. Eventually, we’ll want to clean up the directory structure some but that requires more work in the code to look for the required data files elsewhere. Windows is a bit restrictive on DLLs so we’re probably out of luck on that front.
Did some looking yesterday and it looks like I used the wrong commands for the Start Menu and Desktop shortcut options. WiX has its own options but you need to use properties instead of variables for it: https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-installed-files
Don’t know how to use them yet but I’ll see if I can figure it out. Hopefully those fix that issue. My guess is the poor documentation is a result of CPack just not being used a whole lot: most projects write their own installer scripts separate from CMake.
- You must be logged in to reply to this topic.