Sunday, 18 August 2019

Unix programming part 3

I learned something when researching terminal programming in unix-style operating systems. In order to run something when you are in that directory you need to use ./ prefix in front of the command. So for example wx-config needs to be called ./wx-config.

However this did not solve the problem I had with ./bootstrap not working. After some messages in wxWidgets forum it turns out I have to 'sudo make install' wxWidgets which is against the guideline in installation. If you run 'make' only it's enough for the library and you can compile and run examples. But this is not enough for Code::Blocks which requires 'make install'. This 'install' is something "more" thorough way to install the library, but it's not recommended if you work with several versions of the same library, I guess, because it's copying files under usr (system libraries).

Code::Blocks developers both failed to tell this in their forum and also they don't tell it in install docs to specifically override wxWidgets guideline and use 'make install'. If they had done this there would be way less confusion. I have to say that readme texts for installations are quite bad in both C::B and wxWidgets library, but wx is far better. It serves no purpose to be "elitist" and write vague, hard to understand documents for the program, library etc. and assume that people are experts in unix-style programming.

After all this frustration and being harassed at Code::Blocks forums I finally was able to run ./bootstrap. After that I ran ./configure --with-contrib-plugins=all for Code::Blocks and guess what? It didn't work. Great. I guess this is unix-programming. The error I get is:

configure: error: Package requirements (hunspell) were not met:

No package 'hunspell' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables HUNSPELL_CFLAGS
and HUNSPELL_LIBS to avoid the need to call pkg-config.


Of course I have no idea what that error is. What is package hunspell? Why it's missing from the actual source code package?

Wednesday, 14 August 2019

Unix programming part 2

In this part I'm trying to compile wxWidgets for Code::Blocks. There is a configure script of some sort which seems to be something unix programming requires. It's I guess telling 'make' how to build the project. The configure in readme of wxWidgets is lacking and doesn't work, because "SDK" has to be different. Searching from internet I gather these settings:

../configure --enable-debug --enable-monolithic --with-osx_cocoa --with-macosx-version-min=10.9

It seems to work and also when I type 'make' the project is compiled. There was one problem and it was a missing 'libtoolize' which confusingly is 'libtool' in homebrew (brew install libtool). It will install another libtool version with prefix b, but configure script knows this and is using b-version.

However... when I try to "configure" Code::Blocks with ./bootstrap command which is something C::B has to run first, I get this error:

configure.ac:141: error: possibly undefined macro: AM_OPTIONS_WXCONFIG
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:142: error: possibly undefined macro: AM_PATH_WXCONFIG

When I search internet it seems this is quite common error for whatever reason. The solution is this cryptic command:

export ACLOCAL_FLAGS="-I `wx-config --prefix`/share/aclocal"

But in my case wx-config is not found, it's not recognized as a command. There is wx-config "alias" file in the build directory, but I don't know what it is. Alias is I guess same as shortcut in Windows.

So, I went to Code::Blocks forums to ask about this, but they didn't know the answer and also I get a comment that I don't know anything about osx/unix programming. Well, yes, you are right. But neither do you guys.

I also registered to wxWidgets forums and posted a message about this, but since it's a first message it has to be evaluated by moderators, so we have to wait and see if someone there knows the answer. In Windows if you have precompiled library the only thing you need to worry about is 32/64 bit version of the library, but other than that this "compiling from source" is I think more rare in Windows and it sure seems to be an easier way to get things in the phase where you can work on the actual project's source code.

Sunday, 11 August 2019

Unix programming part 1

I have a Mac Mini as a secondary computer for music "production". Since OSX is unix based I want to see if I can compile something from source and also keep a journey of my experiences as a beginner in unix style programming. The project I want to compile is Code::Blocks, a well known IDE mainly for C/C++.

First thing I need is SVN. It's a version control system like Git. Since I removed XCode I don't have "Apple Developer Tools" which can be installed by writing xcode-select --install in the terminal. This is something I knew, although I wasn't sure if svn was part of it, but it seems to be. The reason I removed XCode was that it can't update itself through my slow internet connection without resulting to an endless loop, for whatever reason. XCode is quite a bloated program, I think the version I had was 6Gb download size. It's an IDE. It's basically a text editor with a swift compiler. Who knows why it got that large.

SVN command downloads the source and places files under 'trunk' in user directory. BUILD file tells you need to install wxWidgets with 'monolithic DLL' which I think could be a reference to Windows .dll which OSX doesn't have. But let's not think about that yet. First I need something called 'autotools'. Google gives an 'ad' page with .io extension I'm not going to click. There is a gnu page, but it doesn't seem to specify what "things" are in autotools. BUILD tells there are at least autoconf, automake, libtool, make, etc. The last two are part of xcode command line tools I guess, because they are found. For autoconf and automake I'm using homebrew which is another tool designed to help installing these "things". I'm not sure what else is in autotools, but I guess when I try to do something it's telling something is missing.

The next step is installing wxWidgets which is a cross platform GUI library.

Saturday, 27 July 2019

The day that would never come

Microsoft Visual Studio has been a great IDE and mainly the one I've been developing my projects, but recently I changed to Code::Blocks. It didn't take much for me to make the decision, because the way VS is developed seems to go downhill fast. Microsoft is breaking features that were always working in reliable way and it tells me their programmers just don't know what they are doing.

I never believed VS development would take such a turn to worse, but then again Windows 10 itself has had some problems with updates breaking things etc. It's hard to understand how this happens, but it must have something to do with quality of programmers and the way development is handled in Microsoft. When you have a renown software it's never guaranteed to stay that way. It's always possible to break it and I believe it is happening right now to Visual Studio for whatever reason.

Open source development is not safe from these problems, we have seen it in projects like Blender 3D which has had quite chaotic development style focusing on some things and leaving others completely dismissed. In that Code::Blocks is a bit different, because it is a decent IDE at least in Windows (OSX users tend to disagree) and has only few problems or missing features I guess. The developers seem to know their stuff and it's possible to harass them directly in the C::B forum which is nice. This is another thing Microsoft is doing completely wrong. Their feedback "forum" for Visual Studio is a failure where your question is quickly buried under thousands of messages and answered by cut-paste indian people who don't understand anything about the IDE itself.

I'm probably going to check out VS in regular intervals just to see what they are doing to it. The way I've set up my projects allows me to switch between IDEs, but I guess it can be dangerous now when you are not sure what VS is doing to your source files. Then again I always do backups as you should and in VS's case really need these days.

Friday, 5 July 2019

Dragonet

Taking off some time from my other projects and starting a new one. With this I'm going to follow different rules than before. It's a traditional RPG rather than a roguelike, but it's going to have some random things. The actual idea is in the implementation with these rules:

1. Completely class-based without public data (only public interface).
2. Inheritance first design.
3. Everything is programmed as a function to a required gameplay feature.
4. External data with parsed dynamic instances.

I think rule 1 is going to be broken in some places, but not inside classes. Mostly in global instances I guess. I think 3 will be an interesting one, because it's the opposite I've done this far. I've always added features without planning them that much and maybe it's one of the reasons I've spent a lot of time wondering how to put everything together.

Saturday, 29 June 2019

Class design tool

I learned today that there is a class design tool in Visual Studio which took some years to figure out. It's not a built-in part of VS2019 but should be. Seeing the class hierarchy in visual level shows "problems" in inheritance very clearly. Although the class hierarchy can be anything you want, but often a tree-like hierarchy is better, from simple to more complex classes.

There are huge stacks of single use classes in both Kaduria and Teemu which looks kind of funny. I think with this new tool it's easier to fix class hierarchy and it's going to be my short term life goal for sure.

I don't yet know what to do with Teemu's github adventure. I actually hate github and source control, because as we saw anything can happen. I feel it's also unneccessarily complex system, but that's typical in the linux/open source scene. Everything is super complex and obfuscated for no clear reason.

Thursday, 6 June 2019

Github failure

Suddenly out of nowhere Visual Studio's github extension reset project files of Teemu (sln, vxproj etc.) to beginning of the project, removing all paths and settings, even to a point that it added already removed files to list of files going to github.

In response I removed github extension, because I still want to develop my projects in Visual Studio. It's still, with all its flaws, much better than let's say Code::Blocks. But since I can't really use or trust github extension it had to go.

I know there are github gui's for other than command line use for github, but it's unclear if I have to remove the current github project and start a new one. After this I've been thinking twice about source control. Yes, it's probably a good idea, but what if something goes wrong? It's feels less reliable now when I know it can change files for no obvious reason. What if it changes some random source files and you can't figure it out until days or weeks later?