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.

No comments: