[Spastic Hamburger]

Looks like we have msitools over here. Will need to look into it

Looks like the fee is only required if the organization is making money so we should be good for now. 🙂

The biggest blocker to having support for other compilers at the moment is the generated code. VS uses its Class Wizard to generate it which isn’t supported by other setups. That’s still on the list. As I recall, MinGW required additional libraries to build stuff that makes heavy use of the Windows API so we’ll need to sort it all out when we get there.

Works for me. I’ll go ahead and start cleaning things up in preparation for 0.7.0 and then squash the CMake branch since the commit log is so messy. Afterwards, I’ll make a new commit bumping up the version number to 0.7.0.

For future versions, I’ll be setting things up to use CMake’s configure file command so that we can just pass the version number to the CMake build command. The code uses several different macros to handle the version number so we’ll need to do some hunting. It’ll also mean adjusting the resource file to use the variables as well but that’s a fairly simple matter (will reply to the resource file comment shortly!) 🙂

Edit:

Added a link to the cross-compilation issue 🙂

[Spastic Hamburger]

MSIX is for the Windows Store as opposed to a standard downloadable installer. May be something to consider down the road, however. It would require more work to get things running and I’m not entirely sure how to set the CI up for it. We can certainly add it to the tracker, though, as a long-term goal. It took Gimp years before they submitted it to the Windows Store, for instance 🙂

Edit: added to the tracker 🙂

I can ask the LOOT folks about the pros and cons as I’m sure they’ve done some consideration already. 🙂

Here’s the list of software that the Windows CI supports out of the box: https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md

There are some package managers in there but I’m unfamiliar with them so I’m not entirely sure how they work.

Anything in there that seems useful, in addition to what we’re already using? As wget isn’t included, we’re using aria2 which supports a similar syntax as wget.

Been a bit of a rough week so I haven’t been able to look too much into the installers yet. Hopefully next week will be better!

[Spastic Hamburger]

I have yet to watch Sweeney Todd. Missed out on the stage version, too. 🙁

Really need to fix that

Florida oranges aren’t doing so hot lately. Citrus greening is hitting the state pretty hard, even home grown ones. On the bright side, the fig trees are doing great

I generally don’t have issues with the wildlife beating me edibles in the wild: plenty of beauty berries still available. Really need to try making jam one day…

Used to harvest blackberries but the city cleared the bushes that I have access to, as well as most of the low hanging grape vines. Fortunately, I can still find some grapes that I can reach 🙂

[Spastic Hamburger]

It looks like you can use wine cmd <batchfile>.bat to run it under wine but I don’t currently have Wine installed.

Should run the same on Windows server as it does on regular Windows. Just a thought: any plans on a PowerShell version? It looks like Microsoft is trying to replace the batchfile language with PowerShell scripts.

Sorry, been busy with trying to figure out how to proceed with MWEdit. The installer business has kind of thrown me for a loop.

[Spastic Hamburger]

Yeah, we may need to forgo CPack as its feature set seems rather limiting. Its Inno support does look better than its WiX support, even though it is very much in the early stages (the docs definitely need some proof-reading). Wouldn’t give us the pretty MSI integration but the docs on using WiX (even the ones on the official Firegiant site) aren’t the best and it was hard for me to follow them when I read them yesterday. I’m just not very good at release engineering.

CPack also has decent NSIS support if we want to try to continue using it instead of simply splitting out the operation.

[Spastic Hamburger]

CMake sets up their shortcuts via template files: https://gitlab.kitware.com/cmake/cmake/-/tree/master/Utilities/Release/WiX?ref_type=heads

Not yet sure how they do it, I’m still analyzing things. It would help if this stuff were documented but alas.

Gimp, on the other hand, uses Inno Setup (as does LOOT) but Inno doesn’t create MSI files, which would be nice for integration. BOSS used NSIS but the syntax was pretty ugly.

[Spastic Hamburger]

CPack has an option, CPACK_WIX_PATCH_FILE, to add a WiX XML fragment to the files. We may be able to leverage that feature. Will take a look at that article when I get the chance and will poke around the web some as well. 🙂

There isn’t a whole lot of information regarding the features to use fragments, though. We may need to do some trial and error.

[Spastic Hamburger]

Okay, made those changes: https://github.com/deathssoul/MWEdit/actions/runs/18993040962

All files should now go in MWEdit/ instead of MWEdit/bin/ and I updated the commands for shortcut creation. 🙂

[Spastic Hamburger]

Perfect! Will get that fixed and then we can do a final test before the version bump and the update script test 🙂

No idea how to get the executable in the root of the MWEdit directory using CPack but I’ll add it to the wishlist!

Edit:

Looks like it’ll take the . option to the destination setting. Will try that for the next test to clean up the layout some

[Spastic Hamburger]

Did the shortcuts work before? We definitely want the options. Apologies, the shortcuts are probably the least documented part of CPack.

Does the license show up properly now?

[Spastic Hamburger]

Okay, here’s a new attempt: https://github.com/deathssoul/MWEdit/actions/runs/18967509920

It should put all files in the bin directory (will add a note to look for the extra data files elsewhere on the tracker later) and hopefully it fixes the issues with desktop shortcuts and Start Menu entries. I also changed the LICENSE file to LICENSE.txt as the docs make it sound like a file extension is required for importing even though standard practice is to leave the extension off on *nix.

[Spastic Hamburger]

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.

[Spastic Hamburger]

Linux doesn’t support Batch files but Shell syntax is similar: https://www.gnu.org/software/bash/manual/bash.html

Most of the basic commands have similar versions on Linux, too. May not be too difficult to put together a Shell script, as well? 🙂

[Spastic Hamburger]

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 .dat files? They should be getting dumped to the same place

Is 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

[Spastic Hamburger]

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 🙂

[Spastic Hamburger]

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 🙂

[Spastic Hamburger]

And for the holidays: https://www.trainworld.com/bachmann-00724-ho-jingle-bell-express-christmas-starter-train-set.html

Lots of possibilities with model trains!

That was quick! Better keep some in reserve! 😛

Oh, got the two for her! When she was visiting my mom once, she fell in love with chewing on them so I got her a couple for here. She loves them!

Yep! Definitely having a good time!

We supposedly have them here but I’ve never come across them before! Likewise with skunks. I’ve seen most of our other wildlife that’s native to the area, including foxes and field mice.

[Spastic Hamburger]

Couldn’t find many scaled power plants available for model railroads (found a few coal plants) and couldn’t find any nuclear power plants that are still available. Only thing I could find was this discontinued one. There are a few blueprint files available for 3D printers, however. Granted, that requires a 3D printer 😛

He really likes the toy! 😀

My dog has rediscovered the cow hoof in the bedroom after over a year. She’s spending a lot of time in there playing with it. She does come out to check on things from time to time and then she goes right back to it 😛

[Spastic Hamburger]

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 .lib files, 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.

[Spastic Hamburger]

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. 🙂

[Author]

Posts