[Spastic Hamburger]

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/src etc when we use it with IL/. 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 🙂

[Spastic Hamburger]

Never had the issue on either OS, myself. I find DisplayPort to be more stable overall than other cable types. It also has nice features, such as daisy-chaining monitors to keep cable clutter to a minimum and better support for high-bit color if you work with a lot of images.

[Spastic Hamburger]

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

[Spastic Hamburger]

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 🙂

[Spastic Hamburger]

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.

[Spastic Hamburger]

Going to try making raspberry cheesecake soon using a modified strawberry cheesecake recipe. Let’s hope it works out!

[Spastic Hamburger]

Picked up the squirrel deck from the Bloomburrow set from Magic the Gathering last month and it’s a pretty fun deck. I’m currently overhauling it, though, to make it more consistent and generally more powerful. I swapped out the included commander Hazel for Chatterfang, also included, which has greatly improved things as it costs three mana instead of five and does a few other helpful things

[Spastic Hamburger]

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

[Spastic Hamburger]

I’m actually not sure how they built the libraries since they didn’t provide any documentation on it. From the looks of things, they intended the build setup to be immutable and assumed 32-bit, which was a bit unusual in 2020. For context, I dropped 32-bit support for BOSS back around 2015 or so. Hopefully they respond to my email 🙂

For decoupling the bundled libraries, we could take a look at the list of included tools here. The Linux script will be much easier for me to manage when we get there but, for now, we should be able to use the included Git command to download everything. As for how to handle checking out stable versions, that’ll require some thinking. Could probably use a dependencies file that we parse or something but ResIL appears to just use a main branch. I’ll need to clone the repository to see if it may just be a limitation with the Sourceforge interface

Oh, neat. They provide a MacOS image so we’ll be able to build for Mac without paying the developer fees. Won’t be able to host it in the App Store without an account but users should still be able to use it

[Spastic Hamburger]

Linux shouldn’t be affecting the build as the CI is set to run Windows Server 2025

[Spastic Hamburger]

Yep, those are the ones. The issue lies with the shared library .lib files. Yeah, will try switching to ResIL at some point. We’ll want to make sure everything is updated, anyways. I don’t know if Meson has an option to do this (will check later) but CMake has a command to download files, which could be helpful.

Unfortunately, I no longer have a Windows install so everything is being done via the CI. At least, on my end. I dropped Windows a few weeks back as it didn’t like my fan controller so I’ve only got access to Linux now.

[Spastic Hamburger]

Okay, I’ve reached out to NimrodPSI. If they’re unable to assist, I’ll go ahead and work on a CMake script so that we can at least rule that out of the equation.

[Spastic Hamburger]

So that error is now gone even though it was showing up all the time the other day and I didn’t change anything in the build script. Meson didn’t get an update either. Looks like an obscure parsing bug.

No idea how to upload the log. Added the upload commands to the action file but apparently it stops the run at the first error so I’m unable to generate it from the CI.

Edit:

Got the log file. Was looking in the wrong spot. And got it uploaded. I’ll review it shortly!

End Edit

Now we’re back to figuring out how to link DLLs to the executable in the build script. There’s zero documentation on this and nothing I’ve found online works 🙁

With CMake, it’s as simple as this. I have yet to determine how to do it in Meson….Will get back to seeing if I can dig up the answer. If I can’t figure it out, we’ll probably need to switch to CMake as at least I know I can likely get it working in it. I’m starting to get a bit frustrated with trying to make Meson work

As near as I can tell, the Meson script is properly set up. :/

There may be something else going on. It looks like the other DLLs are being linked. At least, I think so. It’s complaining about those two specific symbols for some reason. Currently investigating and doing some trial and error. It’s also possible that the more stringent compilation commands are breaking something due to some bad DLL data. In which case, we’d need to rebuild the DevIL libraries. Unfortunately, NimrodPSI didn’t include any documentation or build scripts for those changes. We may need to totally overhaul how the build system uses DevIL. We’ll need to change things anyways for better 64-bit support

For reference, here are the errors:

[198/198] "link" @MWEdit.exe.rsp
FAILED:  MWEdit.exe 
"link" @MWEdit.exe.rsp
project_EsmIconFrame.cpp.obj : error LNK2019: unresolved external symbol __imp_ilutWinLoadImage referenced in function "public: void __cdecl CEsmIconFrame::SetEsmIcon(char const *,bool)" (?SetEsmIcon@CEsmIconFrame@@QEAAXPEBD_N@Z)
project_MWEdit.cpp.obj : error LNK2019: unresolved external symbol __imp_ilInit referenced in function "public: virtual int __cdecl CMWEditApp::InitInstance(void)" (?InitInstance@CMWEditApp@@UEAAHXZ)
D:\a\MWEdit\MWEdit\IL\DevIL.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ilu.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ilu-l.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ILUT.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
MWEdit.exe : fatal error LNK1120: 2 unresolved externals

And here are the grep results for those two symbols:

$ grep --recursive --line-number "ilutWinLoadImage"
IL/ilut.h:212:		ILAPI HBITMAP ILAPIENTRY ilutWinLoadImage(const ILstring FileName, HDC hDC);
grep: IL/ILUT.exp: binary file matches
grep: IL/ILUT.dll: binary file matches
grep: IL/ILUT.lib: binary file matches
project/EsmIconFrame.cpp:142:		hBMP = ilutWinLoadImage(FileBuffer, pDC->GetSafeHdc());
project/EsmIconFrame.cpp:144:		hBMP = ilutWinLoadImage((char *const)pFilename, pDC->GetSafeHdc());

And:

$ grep --recursive --line-number "ilInit"
grep: IL/DevIL.exp: binary file matches
IL/il.h:528:ILAPI ILvoid ILAPIENTRY ilInit(ILvoid);
grep: IL/DevIL.dll: binary file matches
grep: IL/DevIL.lib: binary file matches
project/MWEdit.cpp:320:	ilInit();

If we were to enable Unicode support, that would change the first error slightly. ILstring becomes a wchar when _UNICODE is defined:

#ifdef _UNICODE
	#ifndef _WIN32_WCE
		#include <wchar.h>
	#endif
typedef wchar_t *ILstring;
#else
typedef char *ILstring;
#endif //_UNICODE

TCHAR is a typedef of wchar, as I recall, so things may work differently.

Regarding the second symbol, I’m not sure. ilInit() looks like it’s being used properly.

I’ll try reaching out to NimrodPSI via email to see if they can shed any light on the DLLs they built.

The Meson log is also complaining about the install script but we’ll worry about that later. That’s minor in the scheme of things. Worst case scenario, we simply write a shell script or something.

[Spastic Hamburger]

Good list! Yep, many of the sites are definitely recent. I do notice that they leave off artificial lakes that store power for hydropower plants.

Found it! I see that that kit comes in O-scale. Model trains, anyone? Still want to get into the hobby, just don’t know where I’d put the table! 😛

[Spastic Hamburger]

Whelp. They just added yet another gameplay mechanic to Lorcana, increasing its complexity. I may drop it at the end of this season. I like it because it’s simple and it’s a way to relax when I’m don’t want to deal with a lot of stuff going on like I do with other card games that I play

[Spastic Hamburger]

Progress on MWEdit is currently on hold as I wait to see if the Meson devs can help with the issues. If we can’t get Meson working, I’ll go ahead and use CMake. It isn’t as user friendly but it’s more mature so it should work better. I’ll give them a good week or so to get back to me before I start re-learning how to use CMake

[Spastic Hamburger]

Still banging about. There’s not much about how to link an included binary. When I thought I figured that out, Meson then complained that it wasn’t running under a VS environment even though it was running in a VS environment….

So I changed the backend to use VS as an experiment and then Python crapped out with missing file errors. You can see that one here.

At this point, I think I need to file a bug report and see what the Meson devs have to say.

Edit:

Opened.

In the meantime, progress is pretty much stalled

[Spastic Hamburger]

Sorry, was focused on MWEdit and missed some of this.

We’ve had some Labubus cropping up here but definitely not the intensity that other areas are seeing. In fact, it’s mostly died out here after a few weeks of interest.

Ugh, messing up post history like that is always a pain in the rear. 🙁

On the old site, we actually did a lot of work to merge post histories from several sites just to keep it from getting lost. Took the two of us a few months of work but was definitely worth it. One more reason why vast archives are needed in this day and age

[Spastic Hamburger]

Okay, esm/EsmWinUtils contains only a few things and they’re duplicates of those in project/EsmUtils. The latter is used more often so I’ve commented out the stuff in the former. Not going to delete it just yet as we may change up the structure once things are working but I’ll go ahead and add the two files to the dead code review issue.

Not sure about the other errors right now with the unresolved symbols in the image library (the grep results say that they’re all there) but I’ll need to take a look at them another day. I need a bit of a break 🙂

Looks like those unresolved symbols are the last errors to sort out, though

Edit:

Looks like we may need to add the DLLs to the build script.

Meson doesn’t have a clean way of linking to provided libraries. That’s going to be a tad annoying in the future. Will keep investigating to see what the best way of doing it is. It’ll get figured out. May just go better when I’m not so tired 🙂

[Spastic Hamburger]

Okay, almost got it. Now we’re left with some linking logs after the obvious source issues have been taken care of:

[198/198] "link" @MWEdit.exe.rsp
FAILED:  MWEdit.exe 
"link" @MWEdit.exe.rsp
project_EsmUtils.cpp.obj : error LNK2005: "void __cdecl FindMWRegistryPath(void)" (?FindMWRegistryPath@@YAXXZ) already defined in esm_EsmWinUtils.cpp.obj
project_EsmUtils.cpp.obj : error LNK2005: "char const * __cdecl GetMWDataPath(void)" (?GetMWDataPath@@YAPEBDXZ) already defined in esm_EsmWinUtils.cpp.obj
project_EsmUtils.cpp.obj : error LNK2005: "void __cdecl SetMWDataPath(char const *)" (?SetMWDataPath@@YAXPEBD@Z) already defined in esm_EsmWinUtils.cpp.obj
project_EsmUtils.cpp.obj : error LNK2005: "class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > l_MWDataPath" (?l_MWDataPath@@3V?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@A) already defined in esm_EsmWinUtils.cpp.obj
project_EsmIconFrame.cpp.obj : error LNK2019: unresolved external symbol __imp_ilutWinLoadImage referenced in function "public: void __cdecl CEsmIconFrame::SetEsmIcon(char const *,bool)" (?SetEsmIcon@CEsmIconFrame@@QEAAXPEBD_N@Z)
project_MWEdit.cpp.obj : error LNK2019: unresolved external symbol __imp_ilInit referenced in function "public: virtual int __cdecl CMWEditApp::InitInstance(void)" (?InitInstance@CMWEditApp@@UEAAHXZ)
..\IL\DevIL.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
..\IL\ILU.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
..\IL\ILUT.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
MWEdit.exe : fatal error LNK1120: 2 unresolved externals

Will take a look at those later. The DevIL errors are expected as the repo bundles in the 32-bit DLLs when we’re using 64-bit. Not entirely sure how to go about that. I may need to tell the CI to build the 64-bit version of DevIL. The rest, I’m not sure about at the moment. Will need to look at them later. It sounds like it’s missing an include guard, though

Edit:

Just realized what the duplicates are about: just that, they’re defined several times. Made a mental note a while ago but it didn’t click until just now. If they’re the same, we’ll remove one. Later on, namespaces will keep this sort of thing from happening again. Will fix when I’m back to the computer

Not sure about the other two, those look like issues with the image library. Will take a closer look

[Author]

Posts