See this Nim Forum Topic where this started.
Well I have a working Aporia version on my Yosemite OS X 10.10.2 from the new-suggest
branch of the repository.
BUT the lengths I had to go to get this working are plastered with stuff I did not understand :)
The main problem is that I could not get it to use the libgktsourceview.dylib
.
Neither the one which I got from Homebrew, nor the one I got from a working gedit distribution. Not even compiling it myself (I come to that) made a working dylib for me.
At first I had to get gtk2 working at all.
I did this:
brew install gtk+ --without-x11
This will install a lot of dependencies I do not go into the details. I also installed:
gtk-doc
gtk-engines
gtksourceview
(but that did not work) gdk-pixbuf
I also remember intltool
autoconf
automake
atk
gettext
pkg-config
coreutils
(maybe) glib
which all where involved but some may be not really needed.
First one need to get nim gtk2 to work at all with gtk_quartz. I just write what works for me:
I cloned [email protected]:nim-lang/gtk2.git
and did this (don't laugh) to force it to gtk_quartz:
diff --git a/src/gdk2.nim b/src/gdk2.nim
index 2e6e5c5..d9ec9dc 100644
--- a/src/gdk2.nim
+++ b/src/gdk2.nim
@@ -17,7 +17,7 @@ elif defined(macosx):
# linklib gdk_pixbuf-2.0.0
# linklib atk-1.0.0
const
- lib = "libgdk-x11-2.0.dylib"
+ lib = "libgdk-quartz-2.0.dylib"
else:
const
lib = "libgdk-x11-2.0.so(|.0)"
diff --git a/src/gtk2.nim b/src/gtk2.nim
index 3860101..ad36142 100644
--- a/src/gtk2.nim
+++ b/src/gtk2.nim
@@ -12,7 +12,7 @@ elif declared(gtk_quartz):
lib = "libgtk-quartz-2.0.0.dylib"
elif defined(macosx):
const
- lib = "libgtk-x11-2.0.dylib"
+ lib = "libgtk-quartz-2.0.0.dylib"
# linklib gtk-x11-2.0
# linklib gdk-x11-2.0
# linklib pango-1.0.0
then I nimble install
it and tried the examples
(just ex1.nim and ex2.nim) with a simple cd examples; nim c -r ex1
which should work.
After this I cloned Aporia [email protected]:nim-lang/Aporia.git
and checked it out at new-suggest
.
To make it use the modified GTK2 and not redownload the "original" I changed this:
diff --git a/aporia.babel b/aporia.babel
index 9d57705..07b30dd 100644
--- a/aporia.babel
+++ b/aporia.babel
@@ -7,4 +7,4 @@ license = "GPLv2"
bin = "aporia"
[Deps]
-Requires: "nimrod >= 0.9.2, gtk2#head"
+Requires: "nimrod >= 0.9.2"
After this I compiled it (successfully) with nim c aporia
. But when executed it shows an error about libgtksourceview.(something).dylib
.
As I wrote before, nothing worked to get that go away :(
But continue:
Cloning [email protected]:rhult/ige-mac-integration.git
and applying following changes to make it compile with the current Apple + Homebrew tools:
diff --git a/autogen.sh b/autogen.sh
index 12a8ddc..eb9479f 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -3,11 +3,11 @@
: ${AUTOCONF=autoconf}
: ${AUTOHEADER=autoheader}
-: ${AUTOMAKE=automake-1.9}
-: ${ACLOCAL=aclocal-1.9}
-: ${LIBTOOLIZE=libtoolize}
+: ${AUTOMAKE=automake}
+: ${ACLOCAL=aclocal}
+: ${LIBTOOLIZE=glibtoolize}
: ${INTLTOOLIZE=intltoolize}
-: ${LIBTOOL=libtool}
+: ${LIBTOOL=glibtool}
: ${GTKDOCIZE=gtkdocize}
srcdir=`dirname $0`
@@ -128,7 +128,7 @@ if grep "^AC_PROG_INTLTOOL" $CONFIGURE >/dev/null ||
intltoolize --copy --force --automake
fi
-libtoolize --force || exit $?
+glibtoolize --force || exit $?
if grep "^GTK_DOC_CHECK" $CONFIGURE > /dev/null; then
echo "Running $GTKDOCIZE..."
After this I defined some ENV variables and could compile + install a working version:
./autogen.sh
export CC=clang
export CFLAGS="-Wno-error"
./configure
make
make install
This should leave libigemacintegration.0.dylib
in /usr/local/lib
.
Then I downloaded http://ftp.gnome.org/pub/gnome/sources/gtksourceview/2.10/gtksourceview-2.10.5.tar.gz
(and extracted it).
We need again some ENV set:
export CC=clang
export PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig
./configure --disable-gtk-doc-html
make
make install
This should leave libgtksourceview-2.0.0.dylib
in /usr/local/lib
(and more of course).
THIS... still does not work with Aporia for me. It also does not work in a minimal "import the dylib for one proc" test.
But in the "tests" directory is a working test-widget
which obviously shows that the stuff did compile and "can" work.
After some tries I found out that it uses libgtksourceview-2.0.la
for this test code and tried to use this instead of the dylib in my small testcode. And ... it compiled, linked and worked.
So I thought: Well try that with Aporia!
I made the following additional changes to Aporia:
diff --git a/aporia.nimrod.cfg b/aporia.nimrod.cfg
index ce91d51..d8cb00c 100644
--- a/aporia.nimrod.cfg
+++ b/aporia.nimrod.cfg
@@ -1,5 +1,6 @@
threads:on
threadAnalysis:off
+l:"-lgtksourceview-2.0"
-d:debug
@if windows:
tlsEmulation:on
which adds the library to link to... and then removed the dynlib: lib
part from all the proc in gtksourceview.nim
like this:
(Partial diff only)
diff --git a/gtksourceview.nim b/gtksourceview.nim
index 3662858..a049982 100644
--- a/gtksourceview.nim
+++ b/gtksourceview.nim
@@ -9,12 +9,6 @@
import gtk2, glib2
{.push callConv:cdecl.}
-when defined(windows):
- const lib = "libgtksourceview-2.0-0.dll"
-elif defined(macosx):
- const lib = "libgtksourceview-2.0(|-0).dylib"
-else:
- const lib = "libgtksourceview-2.0.so(|.0)"
type
TSourceLanguageManager*{.pure, final.} = object
@@ -44,159 +38,158 @@ type
const
TEXT_SEARCH_CASE_INSENSITIVE* = 1 shl 2
-proc source_view_new*(): PSourceView {.cdecl, dynlib: lib,
+proc source_view_new*(): PSourceView {.cdecl,
importc: "gtk_source_view_new".}
-proc source_view_new*(buffer: PSourceBuffer): PSourceView {.cdecl, dynlib: lib,
+proc source_view_new*(buffer: PSourceBuffer): PSourceView {.cdecl,
importc: "gtk_source_view_new_with_buffer".}
-proc language_manager_get_default*(): PSourceLanguageManager {.cdecl, dynlib: lib,
+proc language_manager_get_default*(): PSourceLanguageManager {.cdecl,
importc: "gtk_source_language_manager_get_default".}
After this I could compile + link Aporia again nim c aporia
and...
IT WORKS!
I wrote this from memory and some notes I made on the way. It may not be complete but should be enough to get the basic procedure I used for this ugly hack
Cool. Maybe some stuff got updated. Does your solution also don't start the x11 server?