problems compiling Mudlet from source code

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: problems compiling Mudlet from source code

Post by SlySven »

Filion wrote:...In file included from dlgComposer.h:25:0,
from ctelnet.h:33,
from TConsole.h:36,
from TConsole.cpp:24:
ui_composer.h:14:25: fatal error: QtGui/QAction: No such file or directory
compilation terminated.
I've found that one option somewhere in the Qt Creator IDE settings is something about prefixing system #include(s) (the ones in '<' '>'s) with the module (subdirectory?) name. That can throw things off sometimes if wrong as well...

hectorgrey
Posts: 1
Joined: Wed Mar 05, 2014 4:53 pm

Re: problems compiling Mudlet from source code

Post by hectorgrey »

Incidentally (as I just discovered from reading a different thread, but it may be worth reiterating in the sticky): if the source fails to compile and the error message references LUA_GLOBALSINDEX, there's a good chance that your version of the LUA libraries is too recent. The constant that's being called was deprecated in 5.1 and removed in 5.2, so if you have the latest lua libraries but not the 5.1 ones, the code will not compile. It'll probably only be a problem for people using Fedora and Arch, since those distros typically replace older libraries quite quickly, but since the sticky should be one of the first places people look, it seemed a good place to mention it.

wyvie
Posts: 9
Joined: Mon Sep 15, 2014 12:16 pm

Re: problems compiling Mudlet from source code

Post by wyvie »

Hello.
I've been using mud for a while now on ubuntu and debian, and every time i installed it from repos.
Recently i switched to NixOS and was quite sad to find that there's no active package for mudlet in nixos repos.
So i made a build script myself, taking the last commit from sf git.

This is when i found out some strange things. Firstly, about box tells me mudlet's version is 2.1, when title says it's 3.0 rc1. Secondly, i can't see the command box separator (which used to be there), command box is now not surrounded by a white frame (see screenshot) from the mud output. Lastly, src.pro does not contain instructions for the 'make install' routine.
Is this normal behaviour? Is it supposed to be like that? Also, sf says, last commit was about a year ago, which makes me worried. Should I take another commit from the repo for my script?
P.S.: i am using qt 5.2 to build mudlet.
mudlet.png

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: problems compiling Mudlet from source code

Post by SlySven »

Sadly, the repository on SourceForge is not the current focal point for development, instead you'll need to look on the development branch at GitHub, the reason you were not aware of this is that only Heiko(?) I believe (but I am willing to be told I'm wrong) has access to that site so the current active developers can't update things on SF. :(

As I was the one to munge, err modify the code relating to tracking the use of version information throughout the application you should at least find that bit sorted in the current bleading edge code.

The disappearance of things at the bottom of the console, like the surround for the command entry box is a known unknown, we know it happens but I'm not sure we know why - and at least you can see the buttons to the right - they have a habit of disappearing as well in some cases - though hovering over the things sometimes brings them back!

There is some stuff in the pipeline for *nix "make install" and you may well see signs of it in the development code but until code I've proposed to use to locate the lua files that the executable needs to find at runtime and which I'd intended to be put in an out of the binary's sub-directory tree (binary in /usr/local/bin, lua files in /usr/local/share/mudlet/lua) for *nix platforms can play nicely with other OS's assumptions/demands about where things are and work with installers for those platforms then it is not properly usable. There are/is(?) to be a Linux installer as well which I think will bundle up a Mudlet specific collection of the needed libraries.

Qt 5.2 should work fine - I was using it myself until recently - however the development branch has dropped support for Qt 4 - though it should be possible to back port to Qt4.8 (when things have stabilized a bit more) with a little work and I, personally, would like to do that to provide an ("unofficial") upgrade path to Mudlet 3 for system packagers that have not yet adopted Qt5 (e.g. Debian Stable "Wheezy" atm)

wyvie
Posts: 9
Joined: Mon Sep 15, 2014 12:16 pm

Re: problems compiling Mudlet from source code

Post by wyvie »

Thank you very much for the answers, SlySven.
Paths are a difficult question for nixos, since every package in that distro has it's own location, and has no access to other directories, everything has to be in the same directory. I've already bypassed it and made a build script for nix successfully.
I still have to make lua-fs, luasqlite and luazip work correctly, there are even no packages with those libraries and declaring an environment variable is a pain in this distro.
But I have a couple ideas for now, and I'll surely bypass those difficulties. I hope mudlet build script will be merged into the nix package tree soon and I'll go on maintaining it.
Also, if you need any help with code (e.g. many tasks, few devs), you can call me :) I've never worked with telnet or mud clients, but I've been a c++ developer for a long time (tho I prefer java lately).

phasma
Posts: 191
Joined: Sat Aug 03, 2013 7:00 pm
Discord: phasma#4694

Re: problems compiling Mudlet from source code

Post by phasma »

Ideally, all distributions would install to /usr/local/bin and /usr/local/lib but well, we know from experience that never happens. Unfortunate, but such is life.

Also, you poor thing, Wyvie. Java? :p

phasma
Posts: 191
Joined: Sat Aug 03, 2013 7:00 pm
Discord: phasma#4694

Re: problems compiling Mudlet from source code

Post by phasma »

Also, while most people going down the route of rolling their own will not need these links, I will include them for the sake of completeness:

LuaFilesystem: Linky.
LuaSQLLite: Linky.
LuaZip: Linky.

wyvie
Posts: 9
Joined: Mon Sep 15, 2014 12:16 pm

Re: problems compiling Mudlet from source code

Post by wyvie »

fetaera wrote:Also, you poor thing, Wyvie. Java? :p
Maintaining old java code is a lot less pain than maintaining old cpp code :)
Especially if old cpp code is written by a student ^-^

Thanks for the links :)

User avatar
chris
Posts: 493
Joined: Fri Jun 17, 2011 5:39 am

Re: problems compiling Mudlet from source code

Post by chris »

If you wish to contribute -- fork the code and send some pull requests :)

Also get involved on the gitter chat: https://gitter.im/Mudlet/Mudlet

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: problems compiling Mudlet from source code

Post by SlySven »

And can anyone who is thinking of making a contribution: can you ensure you license your code to be GPL2+ i.e. to "GNU Public License Version 2 (or [which is directed toward other people who would want to reuse the code] at you option, any later version)" or compatible with that - we had some issues recently when a contributor was not at the time able to do so (terms of their professional employment) and it threatened to become awkward very quickly until they become able to release under those licence conditions.

Please update the Copyright notice at the top of the file (at least .c, .cpp, .h types, ideally on others if possible) to include your details and the year of your contribution. For a new file you ought to be able to copy from the ./templates sub-directory of the source files (Qt Creator can be set to do this auto-magically, see the Readme there on recent repositories). Whilst it should be possible to determine contributions from the Git commit record this is not foolproof so it is a better bet if you do this - and yes it hasn't been done totally in the past but during that time Heiko will have been tracking where the contributions came from that he incorporated into the SF repository. ;)

The "or later" part is vital because things can change and if we have to change in the future (some new parts of Qt look as if they may be going to be GPLv3+) and if your code is GPLv2 ONLY we will not be able to use it if we go forward to a later version without re-contacting you, or your inheritors, or your legal representative, or your employers and/or uncle Tom Cobley and all to get the required permissions... and that gets messily convoluted very fast. :geek:

Anyhow, with a fresh infusion of new developers, one can see that Mudlet is moving forward and hopefully in a direction that you will like - and if not, join in and help put it on-track to what is wanted. 8-)

Post Reply