Windows build Environment cannot be installed anymore - need a hand

[SlySven]

If you want to try something different I've finally gotten around to putting together something that other people can use to work in a MSYS2+Mingw-w64 environment completely - I haven't publicised this outside of the Core Devs but It might be of interest to you. This is a set of three scripts that can be run after a base install of the MSYS2 product from https://www.msys2.org/ - you can read a draft version of the text and get the scripts here.

There is one change currently needed to get the current development code to build - two enums in the ./src/uiawrapper.h file need to be excluded as they are already present in the header files in a MSYS2+Mingw-w64 environment - I need to get it into a PR as soon as possible but you can fix it by inserting this #if defined(INCLUDE_MAIN_BUILD_SYSTEM) and #endif pair into the code: Now done!

Code: Select all

 #include <oleacc.h>
 #include <uiautomationclient.h>
 #include <uiautomationcore.h> 
 #include <uiautomationcoreapi.h>
 
+#if defined(INCLUDE_MAIN_BUILD_SYSTEM)
 enum NotificationProcessing {
   NotificationProcessing_ImportantAll = 0,
   NotificationProcessing_ImportantMostRecent = 1,
   NotificationProcessing_All = 2,
   NotificationProcessing_MostRecent = 3,
   NotificationProcessing_CurrentThenMostRecent = 4
 };
 
 enum NotificationKind {
   NotificationKind_ItemAdded = 0,
   NotificationKind_ItemRemoved = 1,
   NotificationKind_ActionCompleted = 2,
   NotificationKind_ActionAborted = 3,
   NotificationKind_Other = 4
 };
+#endif // WITH_MAIN_BUILD_SYSTEM
 
 class UiaWrapper {
   UiaWrapper();
 

The first script (the one that installs the needed ontop of the base packages) has some extra packages that are currently commented out - but which (including the MSYS2+Mingw-w64 builds of Qt Creator - rather than Qt's own ones, so no need to sign-up to Qt and download theirs) you will probably want as well. now available by giving the command line option full to the script instead of base - it now requires one of those two and will stop and say so if that is not the case!

Edit: 2023/04/23 Fixed link to the page in the Wiki to actually work - the scripts there have been updated to work "better" as well today.

[freshman]

@Vadi, about MSP segfault: Well sure. At first, this is with 'classical' MSP. According to Mudlet manual/wiki there is a perl regex sound trigger
^!!SOUND\((\S+?)(?: (.+))?\)$
and a similar music trigger
^!!MUSIC\((\S+?)(?: (.+))?\)$
configured, both with actions
deleteLine()
receiveMSP(matches[1])

All this is with a current development tree build on windows.

At login, the mud does an MSP setup like this:

!!SOUND(Off U=http://aldebaran-mud.de/sounds)
!!MUSIC(Off U=http://aldebaran-mud.de/sounds)

No issue with that, but then, a bit later it does:

!!SOUND(Off)
!!SOUND(temple/gong.wav)

this crashes with a segfault here:
1 std::__atomic_base<int>::load atomic_base.h 396 0x8dc014
2 QAtomicOps<int>::loadRelaxed<int> qatomic_cxx11.h 239 0x8dc014
3 QBasicAtomicInteger<int>::loadRelaxed qbasicatomic.h 107 0xa2aa10
4 QtPrivate::RefCount::ref qrefcount.h 55 0xa173db
5 QString::QString qstring.h 1051 0x9d9b71
6 TMediaData::TMediaData TMediaData.h 29 0x8dcdc7
7 TMediaPlayer::getMediaData TMedia.h 62 0xa26040
8 TMedia::<lambda(qint64)>::operator()(qint64) const TMedia.cpp 788 0x795bf4
9 QtPrivate::FunctorCall<QtPrivate::IndexesList<0>, QtPrivate::List<long long>, void, TMedia::getMediaPlayer(TMediaData&)::<lambda(qint64)>>::call(TMedia::<lambda(qint64)> &, void * *) qobjectdefs_impl.h 146 0x79a842
10 QtPrivate::Functor<TMedia::getMediaPlayer(TMediaData&)::<lambda(qint64)>, 1>::call<QtPrivate::List<long long>, void>(TMedia::<lambda(qint64)> &, void *, void * *) qobjectdefs_impl.h 256 0x79a7b1
11 QtPrivate::QFunctorSlotObject<TMedia::getMediaPlayer(TMediaData&)::<lambda(qint64)>, 1, QtPrivate::List<long long>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void * *, bool *) qobjectdefs_impl.h 443 0x79a759
12 void doActivate<false>(QObject *, int, void * *) 0x68dbaea1
13 QMediaPlayer::qt_static_metacall(QObject *, QMetaObject::Call, int, void * *) 0x6b6c5588
14 QMetaMethod::invoke(QObject *, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) const 0x68c8f1fb
15 QMediaObjectPrivate::_q_notify() 0x6b683887
16 QMediaObject::qt_static_metacall(QObject *, QMetaObject::Call, int, void * *) 0x6b683b2c
17 void doActivate<false>(QObject *, int, void * *) 0x68dbada4
18 QTimer::timerEvent(QTimerEvent *) 0x68cba1b2
19 QObject::event(QEvent *) 0x68cb1113
20 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x12af7bef
... <More>

*wild* guess: Maybe it tried to stop a non-running sound and hit some NULL ptr?

Of course there could be some interaction with some else done by the mud at this point.. but I don't think so.

This does not happen with released version 4.17.2 , only with the devel tree/build.

If you really want, you can also try to connect to aldebaran-mud.de 2000 (you can use ssl if you want to) and do:

guest
yes
s
e
e
e
s
strike gong

and see for yourself.

[freshman]

@SlySven: Well this sounds interesting, really.. But as I just got the build environment and I'm also a bit time-constrained, I'd rather not try it yet and break my just created build environment. Hmm... maybe when I'm done with chopping down the MXP PR and resubmitted all pieces.

[Tamarindo]

I created an issue for this and could take a look next weekend: https://github.com/Mudlet/Mudlet/issues/6790

I've noticed with the MSP issue reported above that the directory media/temple gets created, however the file is not being downloaded into it (Mac, 4.17.2, no segfault). When I used the curl command to push the gong.wav file in the directory manually everything worked fine. Clearing the file and directory out and using `lua playSoundFile({name="temple/gong.wav", url="http://aldebaran-mud.de/sounds"})` instead also played it, so this will likely be a quirk tied with MSP and url's. This is something I could sort out. -Tamarindo

[freshman]

@Tamarindo: Well thanks.

About the Windows Build Environment. I still have issues to compile the test code in test/ . From my first work on mudlet some years ago I had some 'make' snippets around that first call qmake with a MudletTest.qmake containing snippets like:

Makefile_TEntityResolverTest {
SOURCES += TEntityResolverTest.cpp
TARGET = TEntityResolverTest
LIBS += \
$$MUDLETBUILD/TEntityResolver.o
}

This will then create individual 'classic' Makefiles which can be used to compile each test. For some of these however - most notably TLinkStoreTest which seems to reference TLuaInterpreter - I failed to get a complete list of dependencies: Not only files within $$MUDLETBUILD but countless references to all libraries/include files installed in severy directories.

On contrary to my attempts some years ago, cmake has now been installed with the sources. But it does not work (when I run cmake test or cmake . within test/ ), it says there is no working CMAKE_CXX_COMPILER resp. that the setting cl does not work. I've not been able to get beyond this. When I force CXX to c++ from mingw it now complains about missing nmake.

What drives me really hazy now is that cmake actually does compile mudlet when the build environment is setup by setup-windows-sdk.ps1 - although in a different build directory than used by QTCreator.

Something I'll try soon is modify the powershell script to make the tests too.. even though there are some files this script recompiles all the time w/o a need, it would be a great help to ensure the cmake files and tests are working b4 I upload them.

[freshman]

Ah, my bad, the powershell script also uses the qmake / make combo. I wonder why it installs cmake first.. but probably there's a reason.

[freshman]

If you want to try something different I've finally gotten around to putting together something that other people can use to work in a MSYS2+Mingw-w64 environment completely - I haven't publicised this outside of the Core Devs but It might be of interest to you. This is a set of three scripts that can be run after a base install of the MSYS2 product from https://www.msys2.org/ - you can read a draft version of the text and get the scripts here.

I just noticed a glitch in some Mudlet code and when trying to work on it, I realized I could no longer build mudlet (main reason seemed the change of the boost version). Using the powershell script I was unable to get a build environment, even after applying all changes of this thread. In addition, the link to download mingw-get (I think it was this one) did no longer work, as the webpage has an expired certificate. Using http worked, but again it seems mingw was not properly installed, an I could not get it too work.

So, I tried msys2 as suggested, and it did actually succeed. Thanks a lot SlySven, you saved my day.

Still, some remarks / issues:

• Maybe make a slight hint where to change the BUILD_TYPE variable. One can figure it out, but a hint like use nano .bash_profile might speedup things.
• Maybe make an earlier hint that the Mudlet repository is being cloned, or maybe skip this and mention people should clone it themselves. People (like me) may already have a clone they are working on. I'm not sure how the autoclone works, if it will ask for a git account first, etc. Anyway, just warn early. To me it was like: I ran setup-windows-sdk.sh and then read on.. And when I got to "it makes a new clone" I thought: Hell no, and cancelled the running setup (hoping this does not screwed anything; it did not)
• When I created a new local copy of my clone (it is in the text, but maybe state more clearly it should be in C:\msys64\home\<user>\src\mudlet) I first ended up cloning into ...\src\mudlet\Mudlet since Mudlet is the name of the repository so this is what you get when you copy into \src\mudlet. This is certainly a silly typo or user error when using the github desktop gui, but it took me a bit of time.
  
  Then it compiles and you can run mudlet from the msys shell.
• Now, your wiki page just jumps to qtcreator, not saying how to run or set it up. You can just run it from the msys shell or find it in C:\msys64\mingw64\bin. Also one could hint people to open the mudlet.pro file in QTCreator and which build set to to use. I used the QT5 environment as it referred to build-MINGW64. I hope it was the right chive.
• You mention to add QMAKE_CC="ccache gcc" QMAKE_CXX="ccache g++" but your screen shot shows "QMAKE_CC=ccache gcc" "QMAKE_CXX=ccache g++". I believe both endup doing the same, but well.
• Unfortunately, when you try to rebuild / compile / run with QTCreator, you get several a compile errors:
  C:\msys64\home\mweller\src\mudlet\src\TLuaInterpreter.cpp Fehler: 'LUA_GLOBALSINDEX' was not declared in this scope
  ../src/TLuaInterpreter.cpp: In member function 'bool TLuaInterpreter::callConditionFunction(std::string&, const QString&)':
  ../src/TLuaInterpreter.cpp21: error: 'LUA_GLOBALSINDEX' was not declared in this scope
  
  I've not been able to fix this, or understand why it happens (as it compiles nicely on the cli). Also it still recompiles some files in the build folder, screwing the folder beyond repair, so I had to completely empty build-MINGW64 by hand. Only then, I can recompile in MSYS again.

So, I do not really need QTcreator for the few things I intend to patch. But it would be nice to have, though. Unfortunately I have not been able to compile something in the mudlet/test folder. Finally, sometimes the debugger might be helpful. I'll see if the cli version of gdb works ok.

In any case, MSYS got me to a build relatively quick, while the 'official' powershell script did not. So, thanks again, SlySven.

[freshman]

Hmm, unfortunately I'm unable to compile and run the contents of mudlet/test. I'm sure someone will ask me to do so (at some point).

@SlySven : any hint on this? I mean I can do cmake and it creates a bunch of files, there is also qmake, but I can't get the two together. I suspect I just need to give the right arguments to the commands, but well.

For the weird compile issues with qtcreator, well.. at least I can use it to edit (and I've plenty of other editors), and I can even use gdb on the command line, so.. it would be great if it worked, but I can get around it. I just assume there are some tiny bits missing from the qtcreator setup.

[freshman]

Found a way to compile test, at least all except TLinkStoreTest which had too many dependencies for me to resolve.

Hmm, I can't attach a tgz here, can I? Ok, for reference:

MudletTest.qmake

Code: Select all

######################################################################
# Automatically generated by qmake (3.1) Sun Nov 8 22:45:42 2020
######################################################################

QT += testlib
INCLUDEPATH += ../src
TEMPLATE = app
INCLUDEPATH += .
INCLUDEPATH += C:\msys64\mingw64\include\QtWidgets

# You can make your code fail to compile if you use deprecated APIs.
# In order to do so, uncomment the following line.
# Please consult the documentation of the deprecated API in order to know
# how to port your code away from it.
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0

# Input
HEADERS += TMxpStubClient.h

MUDLETBUILD = ../build-MINGW64/debug

Makefile_TEntityHandlerTest {
	SOURCES += TEntityHandlerTest.cpp
	TARGET = TEntityHandlerTest
	LIBS += \
		$$MUDLETBUILD/TEntityHandler.o \
		$$MUDLETBUILD/TEntityResolver.o
}

Makefile_TEntityResolverTest {
	SOURCES += TEntityResolverTest.cpp
	TARGET = TEntityResolverTest
	LIBS += \
		$$MUDLETBUILD/TEntityResolver.o
}

Makefile_TLinkStoreTest {
	SOURCES += TLinkStoreTest.cpp
	TARGET = TLinkStoreTest
	LIBS += \
		$$MUDLETBUILD/TLinkStore.o $$MUDLETBUILD/TEntityResolver.o $$MUDLETBUILD/TLuaInterpreter.o $$MUDLETBUILD/TTrigger.o \
		$$MUDLETBUILD/TDebug.o $$MUDLETBUILD/TConsole.o $$MUDLETBUILD/TTextEdit.o \
		$$MUDLETBUILD/TBuffer.o $$MUDLETBUILD/host.o C:\msys64\mingw64\lib\liblua5.1.a
}

Makefile_TMxpTagParserTest {
	SOURCES += TMxpTagParserTest.cpp
	TARGET = TMxpTagParserTest
	LIBS += \
		$$MUDLETBUILD/TMxpTagParser.o $$MUDLETBUILD/TMxpNodeBuilder.o $$MUDLETBUILD/MxpTag.o $$MUDLETBUILD/TStringUtils.o
}

MXP_SOURCE = $$files($$MUDLETBUILD/TMxp*.o)
MXP_SOURCE = $$replace(MXP_SOURCE, $$MUDLETBUILD/TMxpMudlet.o, "")
MXP_SOURCE += $$MUDLETBUILD/MxpTag.o $$MUDLETBUILD/TEntityHandler.o $$MUDLETBUILD/TEntityResolver.o $$MUDLETBUILD/TStringUtils.o
Makefile_TMxpEntityTagHandlerTest {
	SOURCES += TMxpEntityTagHandlerTest.cpp
	TARGET = TMxpEntityTagHandlerTest
	LIBS += $$MXP_SOURCE
}

Makefile_TMxpVersionTagTest {
	SOURCES += TMxpVersionTagTest.cpp
	TARGET = TMxpVersionTagTest
	LIBS += \
		$$MUDLETBUILD/TMxpTagParser.o $$MUDLETBUILD/TMxpNodeBuilder.o $$MUDLETBUILD/MxpTag.o $$MUDLETBUILD/TStringUtils.o \
		$$MUDLETBUILD/TMxpVersionTagHandler.o $$MUDLETBUILD/TMxpTagHandler.o 
}

Makefile_TMxpFormattingTagsTest {
	SOURCES += TMxpFormattingTagsTest.cpp
	TARGET = TMxpFormattingTagsTest
	LIBS += \
		$$MUDLETBUILD/TMxpTagParser.o $$MUDLETBUILD/TMxpNodeBuilder.o $$MUDLETBUILD/MxpTag.o $$MUDLETBUILD/TStringUtils.o \
		$$MUDLETBUILD/TMxpFormattingTagsHandler.o $$MUDLETBUILD/TMxpTagHandler.o 
}

Makefile_TMxpSendTagHandlerTest {
	SOURCES += TMxpSendTagHandlerTest.cpp
	TARGET = TMxpSendTagHandlerTest
	LIBS += \
		$$MUDLETBUILD/TMxpSendTagHandler.o $$MUDLETBUILD/TMxpTagParser.o $$MUDLETBUILD/TMxpNodeBuilder.o \
		$$MUDLETBUILD/MxpTag.o $$MUDLETBUILD/TMxpTagProcessor.o $$MUDLETBUILD/TStringUtils.o $$MUDLETBUILD/TEntityResolver.o \
		$$files($$MUDLETBUILD/TMxp*Handler.o, true) $$MUDLETBUILD/TMxpProcessor.o $$MUDLETBUILD/TEntityHandler.o \
		$$MUDLETBUILD/TMxpElementRegistry.o
}

Makefile_TMxpCustomElementTagHandlerTest {
	SOURCES += TMxpCustomElementTagHandlerTest.cpp
	TARGET = TMxpCustomElementTagHandlerTest
	LIBS += \
		$$MUDLETBUILD/TMxpSendTagHandler.o $$MUDLETBUILD/TMxpTagParser.o $$MUDLETBUILD/TMxpNodeBuilder.o \
		$$MUDLETBUILD/MxpTag.o $$MUDLETBUILD/TMxpTagProcessor.o $$MUDLETBUILD/TStringUtils.o $$MUDLETBUILD/TEntityResolver.o \
		$$files($$MUDLETBUILD/TMxp*Handler.o, true) $$MUDLETBUILD/TMxpElementRegistry.o
}

and Makefile:

Code: Select all

all: Makefile_TEntityHandlerTest Makefile_TEntityResolverTest Makefile_TLinkStoreTest Makefile_TMxpTagParserTest Makefile_TMxpSendTagHandlerTest Makefile_TMxpEntityTagHandlerTest Makefile_TMxpVersionTagTest Makefile_TMxpFormattingTagsTest Makefile_TMxpCustomElementTagHandlerTest
	$(MAKE) -f Makefile_TEntityHandlerTest.Debug
	debug/TEntityHandlerTest
	$(MAKE) -f Makefile_TEntityResolverTest.Debug
	debug/TEntityResolverTest
#	$(MAKE) -f Makefile_TLinkStoreTest.Debug
#	debug/TLinkStoreTest
	$(MAKE) -f Makefile_TMxpTagParserTest.Debug
	debug/TMxpTagParserTest
	$(MAKE) -f Makefile_TMxpSendTagHandlerTest.Debug
	debug/TMxpSendTagHandlerTest
	$(MAKE) -f Makefile_TMxpEntityTagHandlerTest.Debug
	debug/TMxpEntityTagHandlerTest
	$(MAKE) -f Makefile_TMxpVersionTagTest.Debug
	debug/TMxpVersionTagTest
	$(MAKE) -f Makefile_TMxpFormattingTagsTest.Debug
	debug/TMxpFormattingTagsTest
	$(MAKE) -f Makefile_TMxpCustomElementTagHandlerTest.Debug
	debug/TMxpCustomElementTagHandlerTest

Makefile_%:
	qmake -o $@ MudletTest.qmake CONFIG+=$@
	
clean:
	rm -f .qmake.stash Makefile_*
	rm -fr debug release

Drop into mudlet/test and run "mingw32-make.exe" or "mingw32-make.exe clean". Do not forget to clean remove these files b4 you commit or PR to not clutter the development tree.

[SlySven]

Sorry, haven't been paying any attention to the Forums in the last few months. In looking through your recent posts I'll pick out the bits I can quickly advise on:

Unfortunately, when you try to rebuild / compile / run with QTCreator, you get several a compile errors:

Code: Select all

C:\msys64\home\mweller\src\mudlet\src\TLuaInterpreter.cpp:15147: Fehler: 'LUA_GLOBALSINDEX' was not declared in this scope
../src/TLuaInterpreter.cpp: In member function 'bool TLuaInterpreter::callConditionFunction(std::string&, const QString&)':
../src/TLuaInterpreter.cpp:15147:21: error: 'LUA_GLOBALSINDEX' was not declared in this scope

That is caused by the Lua system defaulting to a later Lua (probably 5.4) and the LUA_GLOBALINDEX is something that went away after the Lua 5.1 that Mudlet uses. To fix that you need to configure the LUA_PATH and LUA_CPATH variables to point at the 5.1 instead of the 5.4 libraries/modules. When using luarocks you'll need to provide an additional "--lua-version=5.1" argument. From a MINGW64 type (bash) shell "luarocks --lua-version=5.1 --tree="user" path" command will give the values you need (my scripts do install Luarocks in a manner that allows both 32 and 64 bit versions to coexist - which the default does not) for both those to access the right Lua components. However if you use that command yourself you will also want to clean up the mix of directory separators that that command produces - I convert every C:\ to /c/ and then every remaining \ to / - note that you'll need to identify the \ as \\ to correctly escape it. I use a simple pair of "sed" scripts to do convert the individual values:

Code: Select all

$ luarocks --lua-version=5.1 --tree="user" path --lr-path | sed 's|C:\\|/c/|g' | sed 's|\\|/|g' # for LUA_PATH
... # copy this as the value for LUA_PATH into Qt Creator
$ luarocks --lua-version=5.1 --tree="user" path --lr-cpath | sed 's|C:\\|/c/|g' | sed 's|\\|/|g' # for LUA_CPATH
... # copy this as the value for LUA_CPATH into Qt Creator

I've entered this whilst on Linux so can't show the exact things I have in Windows. However you can put this into the "Build Environment" and it will be something like this (except it will have ";" separated paths beginning with /c/msys64/mingw...:

I haven't checked the CMake build process - but I do recall it does tend to offer a range of build targets and try and build all of them but I've never bothered with the tests, though the mudlet application did use to build with that as well as QMake from what I recall - for comparison the main build environment (not this one) doesn't work on CMake on Windows and there is a long standing open issue for it Issue 806.