Release manager

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] Release manager” on Tue, 25 Mar 2008
12:57:12 +0100,
Sjoerd S. [email protected] wrote:

IMHO we should get the two efforts merged ASAP (There should be only ever have
been one effort in the first place, but oh well)… What was the rationale of
doings this anyways, i’m pretty sure people know about my bindings. And i’d hope
the ruby-gnome2 team doesn’t have NIH syndrome.

NIH syndrome?

I tried to contribute your bindings (not the bindings in the
Ruby-GNOME2 repository) and submitted a patch two years
ago. But the patch was derelict until two days ago. So I
understood your bindings are not maintained. This is the
reason why I started to updated Ruby/GStreamer.

If we can change to a more sane releases and release everything as
seperate package, i’m happy to merge my bindings back into the main repository.

If you want to release it as a separate package, you can
do. But Ruby/GStreamer may depend on unreleased Ruby/GLib.

Thanks,

kou

On Wed, Mar 26, 2008 at 08:21:04PM +0900, Kouhei S. wrote:

Ruby-GNOME2 Project Team: Non-consistent coding style,
It’s moving over to my own coding style, but that’s easy to change back
to the
``ruby-gnome2’’ coding style as needed. Is there a document describing
what
this style exactly is ? (Exept for the emacs style file)

low Ruby/GLib integration (e.g. rbgst_new_gstobject)

Hmm, exactly the same function is in your gstreamer bindings and afaik
stems
from the original 0.8 bindings. I don’t see why this means low
integration.

Ruby-GNOME2 Project’s naming convention and so on.

Because of the gst010 name or ? That was basically there to allow
parallel
installability of the 0.8 and 0.10 bindings.

It seems that most of these things are style issues though and not
fundamental
issues with the implemtation.

And thus set yourself up to hit the same issues that are
already fixed in my bindings. I can already tell you that the
in the current state Ruby/Gstreamer will get deadlocks and potentially
crashes if used for anything but a non-trivial program.
Please tell us them.

I didn’t do a full comparison but some of the things i noticed:

  • The bin_add doesn’t take into account that the bin takes over
    ownership if
    GstObjects are floating.
  • You expose gst_object_sink to the ruby layers, which your really not
    supposed too. As soon as you wrap an GstObject you should take
    ownership and
    sink any floating object (which also solves the previous issue). And
    crashes
    with playbin which basically behaves like a bin.
  • You don’t cope with the fact that state changes to a ``lower’’ state
    are
    synchronous (the call will block), but to change state several ruby
    callbacks
    might be called. Which won’t work as your in a blocking
    gst_element_set_state
    call. Hence your program will deadlock.

And i’m sure there will be more if i go in for a closer look.

And please tell us a feature list that your bindings has
but ours doesn’t have.

Actually tested and working in non-trivial programs is the main feature.
Gstreamer is somewhat more complex then most other things (mostly
because its
heavy use of threads and the way ruby (doesn’t) handle them), you can’t
naively
bind it and expect things to work.

  • 0.18.2: separated release. It will depend on Ruby/GLib 0.18.0.

I think that makes sense. What i’d like to see if we do things this way.
Is
that say 0.17.0 is both released as one big tarball and a set of smaller
ones.
For distributions (like say Debian) it would be great to have one source
tarball per component instead of the big blob with everything. Let’s see
what
Joachim thinks about this all :slight_smile:

I’ll see if i can get a few hours this weekend to create a set of
patches to
merge my binding into yours. I still think you’ve wasted a lot of effort
by
doing things this way, but it’s more important to have one good solid
set of
gstreamer bindings then two different ones just because the maintainers
can’t
work out their differences :slight_smile:

For now, please hold the Ruby-Gnome2 0.17.0 release (with gstreamer)
untill
these issues are resolved. Or release 0.17.0 without gstreamer and have
a
seperate gstreamer 0.17.1 release later on. I don’t think it’s
benificial for
anyone to have a release of Ruby/Gstreamer in its current state.

Sjoerd

“I gained nothing at all from Supreme Enlightenment, and for that very
reason it is called Supreme Enlightenment.”
– Gotama Buddha

Hi,

Am Mittwoch, den 26.03.2008, 20:21 +0900 schrieb Kouhei S.:

IMHO thats not usefull, cause there is no way for bugfix releases (wich
we sould do in the future). The Ruby-GNOME version numbering should go
up to four numbers and for GStreamer inbetween releases the nano Version
sould be used. In this way we keep the numbering consistent.

* 0.17.0.0: with Ruby-GNOME2 0.17.0.0 release

  • 0.17.0.1: separated release. It will depend on Ruby/GLib 0.17.0.0
  • 0.17.0.2: separated release. It will depend on Ruby/GLib 0.17.0.0
  • 0.17.1.0: Ruby-GNOME bugfix release. It will depend on Ruby/GLib
    0.17.1.0
  • 0.17.1.1: separated release. It will depend on Ruby/GLib 0.17.1.0

Cheers, detlef


Sjoerd S. wrote:

  • 0.18.2: separated release. It will depend on Ruby/GLib 0.18.0.

I think that makes sense. What i’d like to see if we do things this way.
Is
that say 0.17.0 is both released as one big tarball and a set of smaller
ones.
For distributions (like say Debian) it would be great to have one source
tarball per component instead of the big blob with everything. Let’s see
what
Joachim thinks about this all :slight_smile:

Write a script which does something like that for debian packages if you
want. But releasing every single component as source tarball doesn’t
make any sense. Installing Ruby-Gnome would be like “sorry, you need to
download this tarball in order to continue” all the time.

What could be done is to separate core packages and additional packages.
But not 24 packages.

For now, please hold the Ruby-Gnome2 0.17.0 release (with gstreamer)
untill
these issues are resolved. Or release 0.17.0 without gstreamer and have
a
seperate gstreamer 0.17.1 release later on. I don’t think it’s
benificial for
anyone to have a release of Ruby/Gstreamer in its current state.

I really would like to release 0.17 soon. But I’ll wait to make my
decision if and which version to release until you guys finally come to
a conclusion which code base to work on with.
Please don’t let this take too long.

Thanks,
Joachim

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] Release manager” on Wed, 26 Mar 2008
13:19:14 +0100,
Sjoerd S. [email protected] wrote:

Your bindings have several problems to use in the
Ruby-GNOME2 Project Team: Non-consistent coding style,

It’s moving over to my own coding style, but that’s easy to change back to the
``ruby-gnome2’’ coding style as needed. Is there a document describing what
this style exactly is ? (Exept for the emacs style file)

If you don’t want to see
http://svn.ruby-lang.org/repos/ruby/trunk/misc/ruby-style.el,
see other C sources in Ruby-GNOME2 Project.

low Ruby/GLib integration (e.g. rbgst_new_gstobject)

Hmm, exactly the same function is in your gstreamer bindings and afaik stems
from the original 0.8 bindings. I don’t see why this means low integration.

We should use GOBJ2RVAL.

I use it just for now because I’m working step by step. It
will be removed in the feature. But your bindings completely
use it. It will not be removed from your bindings in the
feature.

Ruby-GNOME2 Project’s naming convention and so on.

Because of the gst010 name or ? That was basically there to allow parallel
installability of the 0.8 and 0.10 bindings.

e.g.: RGST_* macro names for converting to Ruby object from
GStreamer object. We should use XXX2YYY name for those macro.

The origin of naming conversion is Ruby/GStreamer for
GStreamer 0.8. We should fix it in the feature.

It seems that most of these things are style issues though and not fundamental
issues with the implemtation.

No. It’s important because WE are working TOGETHER.

  • The bin_add doesn’t take into account that the bin takes over ownership if
    GstObjects are floating.
  • You expose gst_object_sink to the ruby layers, which your really not
    supposed too. As soon as you wrap an GstObject you should take ownership and
    sink any floating object (which also solves the previous issue). And crashes
    with playbin which basically behaves like a bin.

OK. They will be fixed.

  • You don’t cope with the fact that state changes to a ``lower’’ state are
    synchronous (the call will block), but to change state several ruby callbacks
    might be called. Which won’t work as your in a blocking gst_element_set_state
    call. Hence your program will deadlock.

Do you have a test case?

Thanks,

kou

On Wed, Mar 26, 2008 at 10:14:17PM +0900, Kouhei S. wrote:

“Re: [ruby-gnome2-devel-en] Release manager” on Tue, 25 Mar 2008
what this style exactly is ? (Exept for the emacs style file)

If you don’t want to see
http://svn.ruby-lang.org/repos/ruby/trunk/misc/ruby-style.el,

I did see it. But i’m not an emacs user and it’s not so easy to figure
out what
it means if you don’t speak emacs/lisp :slight_smile:

see other C sources in Ruby-GNOME2 Project.

Ok. Reverse engineering coding style is always a big nasty though :slight_smile:

low Ruby/GLib integration (e.g. rbgst_new_gstobject)

Hmm, exactly the same function is in your gstreamer bindings and afaik stems
from the original 0.8 bindings. I don’t see why this means low integration.

We should use GOBJ2RVAL.

Hmm, well GstObjects need a bit of special handling. See the points
about
floating i made earlier. If we can get GOBJ2RVAL to support sinking
objects
where needed then that could work.

I looked over at the python bindings a bit and their gobject bindings
allow one
to register sink_handlers per object type. (As both GTK objects and
GstObjects
have their own _sink methods). Currently the Ruby Gtk bindings do sink
stuff on
their own too, so maybe that could be synced.

I use it just for now because I’m working step by step. It
will be removed in the feature. But your bindings completely
use it. It will not be removed from your bindings in the
feature.

Well just as much as yours and nothing that can’t be changed in either
:slight_smile:
Basically i’m just wondering why you took the old 0.8 bindings as a
starting
point instead of my 0.10 ones… But we don’t have to discuss that
further if
you don’t want too.

It seems that most of these things are style issues though and not
fundamental issues with the implemtation.

No. It’s important because WE are working TOGETHER.

Exactly. Which is what i’ve been saying all along. And why i mentioned
in my
previous mail that i’ll spent some time next weekend to create a
patchset to
merge the two.

  • The bin_add doesn’t take into account that the bin takes over ownership if
    GstObjects are floating.
  • You expose gst_object_sink to the ruby layers, which your really not
    supposed too. As soon as you wrap an GstObject you should take ownership
    and sink any floating object (which also solves the previous issue). And
    crashes
    with playbin which basically behaves like a bin.

OK. They will be fixed.

Nice. I’d still recommend looking at how my bindings cope with these
things
though :slight_smile:

  • You don’t cope with the fact that state changes to a ``lower’’ state are
    synchronous (the call will block), but to change state several ruby
    callbacks might be called. Which won’t work as your in a blocking
    gst_element_set_state call. Hence your program will deadlock.

Do you have a test case?

Hmm. Not a simple one at this point. Probably the easiest way to do this
is to
connect to the handoff signal of identity element and then switch the
pipeline
back and forward to playing continously. I can’t come up with one from
the
top of my head that will hit this case 100%.

Again, have a look at my bindings for a way to fix this or just wait a
bit for
the merging patchset.

Sjoerd

Given a choice between grief and nothing, I’d choose grief.
– William Faulkner

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] Release manager” on Wed, 26 Mar 2008
14:47:07 +0100,
Sjoerd S. [email protected] wrote:

We should use GOBJ2RVAL.

Hmm, well GstObjects need a bit of special handling. See the points about
floating i made earlier. If we can get GOBJ2RVAL to support sinking objects
where needed then that could work.

It can be done in our bindings. I hope you look our bindings
before you say “look my bindings, look my bindings, …”.

Index: test/test_object.rb

— test/test_object.rb (revision 2869)
+++ test/test_object.rb (working copy)
@@ -1,13 +1,6 @@
class TestObject < Test::Unit::TestCase
include GstTestUtils

  • def test_floating
  • sink = create_element(“fakesink”)
  • assert(sink.floating?)
  • sink.sink
  • assert(!sink.floating?)
  • end
  • def test_name
    sink = create_element(“fakesink”, “my-fakesink”)
    assert_equal(“my-fakesink”, sink.name)
    Index: src/rbgst-object.c
    ===================================================================
    — src/rbgst-object.c (revision 2869)
    +++ src/rbgst-object.c (working copy)
    @@ -24,21 +24,33 @@

#define SELF(self) (RVAL2GST_OBJ(self))

+extern VALUE rbgobj_get_value_from_gobject(GObject* gobj, gboolean
alloc);
+
+static RGConvertTable table = {0};
+
/* Class: Gst::Object

  • Basis for the GST object hierarchy.
    */

-/*

    • Method: floating?
    • Checks if the Gst::Object::FLAG_FLOATING flag is set on the object.
    • Returns: true if the flag is set, false otherwise.
  • */
    static VALUE
    -object_is_floating(VALUE self)
    +rbgst_object_instance2robj(gpointer instance)
    {
  • return CBOOL2RVAL(GST_OBJECT_IS_FLOATING(SELF(self)));
  • VALUE object;
  • object = rbgobj_get_value_from_gobject(instance, FALSE);
  • if (!NIL_P(object))
  • return object;
  • object = rbgobj_get_value_from_gobject(instance, TRUE);
  • if (NIL_P(object))
  • return object;
  • if (GST_OBJECT_IS_FLOATING(instance)) {
  • gst_object_ref(instance);
  • gst_object_sink(instance);
  • }
  • return object;
    }

static VALUE
@@ -47,23 +59,19 @@
return CBOOL2RVAL(gst_object_set_name(SELF(self),
RVAL2CSTR(name)));
}

-static VALUE
-object_sink(VALUE self)
-{

  • gst_object_sink(SELF(self));
  • return Qnil;
    -}

void
Init_gst_object(void)
{
VALUE cGstObject;

  • table.type = GST_TYPE_OBJECT;
  • table.instance2robj = rbgst_object_instance2robj;
  • RG_DEF_CONVERSION(&table);
  • cGstObject = G_DEF_CLASS(GST_TYPE_OBJECT, “Object”, mGst);
  • rb_define_method(cGstObject, “floating?”, object_is_floating,0);
    rb_define_method(cGstObject, “set_name”, object_set_name, 1);

  • rb_define_method(cGstObject, “sink”, object_sink, 0);

    G_DEF_SETTERS(cGstObject);

I use it just for now because I’m working step by step. It
will be removed in the feature. But your bindings completely
use it. It will not be removed from your bindings in the
feature.

Well just as much as yours and nothing that can’t be changed in either :slight_smile:

Did you look ours? Ours use GOBJ2RVAL except for we didn’t
update. Ours doesn’t need to change it because we doesn’t
need it.

Basically i’m just wondering why you took the old 0.8 bindings as a starting
point instead of my 0.10 ones… But we don’t have to discuss that further if
you don’t want too.

I mentioned that yours have several problems. They are
serious implement design problems for us.

Nice. I’d still recommend looking at how my bindings cope with these things
though :slight_smile:

BTW, do you have a test case for the problem? We can’t
commit our fix until we confirm the problem and our fix the
problem.

top of my head that will hit this case 100%.
As I mentioned above, we can’t commit our fix until we
confirm the problem and our fix the problem.

Again, have a look at my bindings for a way to fix this or just wait a bit for
the merging patchset.

I hope that you submit test cases with the patchset.

Thanks,

kou

Shin guey Wong wrote:

Which compiler the future Ruby-Gnome2 will use? VC6 or MinGW.
I would prefer MinGW. I see no reason to use an outdated compiler.

Is there any release manager for windows? Base on the reply, seems like
nobody have windows box to work on it.

Well basically I’ve a win32 virtual machine. But it’s not running well
and it’s hard to use for me. I didn’t get the bindings working on
another windows machine, yet.

If you want to participate as release manager for windows binaries,
you’re welcome!

Joachim G.

Kouhei S. wrote:

Hi,
We want a release manager who will do the following work:

  • You will try to build on supported platform that will be
    decided by you.
    (e.g. ruby >= 1.8.x, GTK+ >= 2.x.x, Linux, FreeBSD,
    Windows, MacOSX, …)

    kou

Which compiler the future Ruby-Gnome2 will use? VC6 or MinGW. Luis
Lavena is working on the Ruby OCI using MinGW. Although there are still
some issue on it but it looks promising. So, will the Ruby-Gnome2 will
provide an installer for windows build with MinGW? I prefer for the
MinGW solution because it is hard to get VC6 compiler now.

Is there any release manager for windows? Base on the reply, seems like
nobody have windows box to work on it.

Regards,
Shin Guey

Shin guey Wong wrote:

I am trying to compile the ruby-gnome first(the old version downloaded
from the source forge website, not the trunk src). I still having some
problem on compiling the ruby gnome now, may be I don’t have some
require library.
Some modules are not working on win32 environments since.

I would suggest to start with the current trunk because there are many
changes since 0.16.0.

This guide may be helpful:
http://ruby-gnome2.sourceforge.jp/hiki.cgi?compile_mingw

Still working on it now. (the GLADE for Windows website
is down…at least I can’t download the gtk-dev package from it. I am
trying to download 1 from teh GTK+ website now)

Yes the link is dead. I’ll fix the wiki later.
You can download it here:

Joachim G. wrote:

Shin guey Wong wrote:

Which compiler the future Ruby-Gnome2 will use? VC6 or MinGW.
I would prefer MinGW. I see no reason to use an outdated compiler.

Is there any release manager for windows? Base on the reply, seems like
nobody have windows box to work on it.

Well basically I’ve a win32 virtual machine. But it’s not running well
and it’s hard to use for me. I didn’t get the bindings working on
another windows machine, yet.

If you want to participate as release manager for windows binaries,
you’re welcome!

Joachim G.

I am still new to ruby-gnome now. I just compiled the MinGW ruby version
from Luis L… It is still not really complete yet. Some extension
doesn’t exist/compile like the curse ext, dbm(not sure what is this),
tcl binding. The readline also doesn’t pass the ruby test. I haven’t
tried the entire feature, it is usable in the normal irb mode with
readline though.

I am trying to compile the ruby-gnome first(the old version downloaded
from the source forge website, not the trunk src). I still having some
problem on compiling the ruby gnome now, may be I don’t have some
require library. Still working on it now. (the GLADE for Windows website
is down…at least I can’t download the gtk-dev package from it. I am
trying to download 1 from teh GTK+ website now)

If I able to compile on windows, I can help to release and test the
windows binaries.

Regards,
Shin Guey

Shin guey Wong wrote:

make[1]: Entering directory
`/c/Devel/installer3/sandbox/ruby-gnome2-all-0.16.0/glib/src’
gcc -I. -I.
-Ic:/Devel/installer3/sandbox/ruby_mingw/lib/ruby/1.8/i386-mingw32 -I.
-DHAVE_RB_DEFINE_ALLOC_FUNC -DHAVE_RB_BLOCK_PROC -DHAVE_OBJECT_ALLOCATE
-DHAVE_NODE_ATTRASGN -DHAVE_G_THREAD_INIT -DHAVE_G_MAIN_DEPTH
-DHAVE_G_LISTENV -DHAVE_RB_CHECK_ARRAY_TYPE -DRUBY_GLIB2_COMPILATION
-Ic:/Devel/installer3/sandbox/ruby_mingw/lib/ruby/site_ruby/1.8/i386-msvcrt
-g -O2 -Wall -IC:/PROGRA~1/PyGTK/GTK/INCLUDE

Just observe that there are some GTK from the python mix up. Might need
to remove it first.

-Ic:/Devel/installer3/sandbox/gtk/include/glib-2.0
-Ic:/Devel/installer3/sandbox/gtk/lib/glib-2.0/include
-Ic:/Devel/installer3/sandbox/gtk/include/glib-2.0
-Ic:/Devel/installer3/sandbox/gtk/lib/glib-2.0/include -mms-bitfields
-c glib-enum-types.c
glib-enum-types.c: In function g_markup_collect_type_get_type': glib-enum-types.c:292: error: syntax error before ',' token glib-enum-types.c:293: error: syntax error before ',' token glib-enum-types.c:294: error: syntax error before ',' token make[1]: *** [glib-enum-types.o] Error 1 make[1]: Leaving directory/c/Devel/installer3/sandbox/ruby-gnome2-all-0.16.0/glib/src’
make: *** [all] Error 2

Joachim G. wrote:

This guide may be helpful:
http://ruby-gnome2.sourceforge.jp/hiki.cgi?compile_mingw

Yes the link is dead. I’ll fix the wiki later.
You can download it here:
http://wingtk.sourceforge.net/

I am follow the wiki guide to compile the src now. The wingtk seems very
outdated. I downloaded 1 from the gtk+ website (gtk±2.12.9-bundle.zip)
But I failed to compile Glib in ruby-gnome2-all-0.16.0 src.

I will try to download the latest src from the trunk and compile again
tonight. May be the ruby binding doesn’t match the gtk+ version 2.12.9

Regards,
Shin Guey

Here the error message:
(* I take look at the line 292, 293 & 294, there is nothing wrong with
that so I guess it cannot get the constant or macro in that line).

make[1]: Entering directory
/c/Devel/installer3/sandbox/ruby-gnome2-all-0.16.0/glib/src' gcc -I. -I. -Ic:/Devel/installer3/sandbox/ruby_mingw/lib/ruby/1.8/i386-mingw32 -I. -DHAVE_RB_DEFINE_ALLOC_FUNC -DHAVE_RB_BLOCK_PROC -DHAVE_OBJECT_ALLOCATE -DHAVE_NODE_ATTRASGN -DHAVE_G_THREAD_INIT -DHAVE_G_MAIN_DEPTH -DHAVE_G_LISTENV -DHAVE_RB_CHECK_ARRAY_TYPE -DRUBY_GLIB2_COMPILATION -Ic:/Devel/installer3/sandbox/ruby_mingw/lib/ruby/site_ruby/1.8/i386-msvcrt -g -O2 -Wall -IC:/PROGRA~1/PyGTK/GTK/INCLUDE -Ic:/Devel/installer3/sandbox/gtk/include/glib-2.0 -Ic:/Devel/installer3/sandbox/gtk/lib/glib-2.0/include -Ic:/Devel/installer3/sandbox/gtk/include/glib-2.0 -Ic:/Devel/installer3/sandbox/gtk/lib/glib-2.0/include -mms-bitfields -c glib-enum-types.c glib-enum-types.c: In function g_markup_collect_type_get_type’:
glib-enum-types.c:292: error: syntax error before ‘,’ token
glib-enum-types.c:293: error: syntax error before ‘,’ token
glib-enum-types.c:294: error: syntax error before ‘,’ token
make[1]: *** [glib-enum-types.o] Error 1
make[1]: Leaving directory
`/c/Devel/installer3/sandbox/ruby-gnome2-all-0.16.0/glib/src’
make: *** [all] Error 2

Shin guey Wong wrote:

I am follow the wiki guide to compile the src now. The wingtk seems very
outdated. I downloaded 1 from the gtk+ website (gtk±2.12.9-bundle.zip)
But I failed to compile Glib in ruby-gnome2-all-0.16.0 src.

I will try to download the latest src from the trunk and compile again
tonight. May be the ruby binding doesn’t match the gtk+ version 2.12.9

I have better luck with the ruby-gnome2 at the trunk.

Which rcairo version I should use? I am using the 1.2.0 as suggested in
the wiki.

Here are the issue I encounter when compiling the ruby-gnome:

  1. compiling glib:
    I have to manually edit the makefile to add a new include directory
    because it complaint libintl.h doesn’t found. The file located at the
    gtk/include folder. So, I manually added this directory into the
    makefile then it works.

  2. compiling gtk:
    missing gtkpagesetupunixdialog.h. I have to download this file from the
    gtk+ subversion.

Here is the modules I able to compile:
glib, gdkpixbuf, pango, atk, gtk.

Here is the rest of modules which I not able to compile:
bonobo, bonoboui, gconf, gnome, gnomecanvas, gnomeprint, gnomeprintui,
gnomevfs, gstreamer, gtkglext, gtkhtml2, gtkmozembed, gtksourceview,
libart, libgda, libglade, panel-applet, poppler, rsvg, vte

I would like to compile the libglade module but I have no idea how to do
it. I have the glade3 windows version. But I am not sure how to compile
it with ruby-gnome…For the rest of the module, I think some module is
not available in windows. But the previous ruby-gnome2 installer provide
more module like gtksourceview, gtkhtml2…etc.

Regards,
Shin Guey

Just tested the ruby gnome version I compile is not usable…
it complain that the procedure entry point g_timeout_add_seconds_full
could not be located in the dynamic link library libglib-2.0-0.dll

I just found that my old gtk/bin is still in the path. might need to try
to compile again by removing the old gtk. I will try again tomorrow
night…Hopefully things will go better.

It is harder to compile the ruby-gnome than I think…:frowning:

Regards,
Shin Guey

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] Release manager” on Tue, 1 Apr 2008
07:22:18 +0200,
Shin guey Wong [email protected] wrote:

-DHAVE_G_LISTENV -DHAVE_RB_CHECK_ARRAY_TYPE -DRUBY_GLIB2_COMPILATION
glib-enum-types.c:294: error: syntax error before ‘,’ token
make[1]: *** [glib-enum-types.o] Error 1
make[1]: Leaving directory
`/c/Devel/installer3/sandbox/ruby-gnome2-all-0.16.0/glib/src’
make: *** [all] Error 2

It had been fixed in trunk.

Thanks,

kou

Shin guey Wong wrote:

Just tested the ruby gnome version I compile is not usable…
I just found that my old gtk/bin is still in the path. might need to try
to compile again by removing the old gtk. I will try again tomorrow
night…Hopefully things will go better.

Regards,
Shin Guey

I had remove the old stuff and recompile all the module. Now, I have a
working ruby-gnome2 for the standard module as my last post. (glib,
gdkpixbuf, pango, atk, gtk)

Now, I need someone to tell me how do I compile the extra module in
windows like:

  • libglade
  • gtksourceview
  • gnomeprint
  • gnomeprintui
  • gtkglext

Regards,
Shin Guey

Shin guey Wong wrote:

Now, I need someone to tell me how do I compile the extra module in
windows like:

  • gtksourceview
  • gnomeprint
  • gnomeprintui
  • gtkglext

AFAIK those packages are not available for win32 now.

Joachim G. wrote:

Shin guey Wong wrote:

Now, I need someone to tell me how do I compile the extra module in
windows like:

I don’t use the gtk-dev from the link above. Instead, I use the gtk+
package from the Gtk+ website. I will try to recompile again with the
gtk-dev above.

  • gtksourceview
  • gnomeprint
  • gnomeprintui
  • gtkglext

AFAIK those packages are not available for win32 now.

Current ruby-gnome installer contains much more packages. Refer here:
http://ruby-gnome2.sourceforge.jp/hiki.cgi?News_20070212_1

Shin guey Wong wrote:

I don’t use the gtk-dev from the link above. Instead, I use the gtk+
package from the Gtk+ website. I will try to recompile again with the
gtk-dev above.

I had downloaded the gtk-dev, which version 2.10.11 from the website
above. A bit older than the package from the gtk+ website which version
is 2.12.9.
However, the gtk-dev package contain more package included in its own.
Here is the list of package I had compiled:
*glib
*gdkpixbuf
*pango
*atk
*gtk
*gtkglext
*libart
*libglade

It is getting much better now. I am able to run my program, which using
the glade file. Thanks for the links.

There is one problem that blocking me for long time to get the package
compile. The pkg-config.exe comes with the gtk-dev is not usable with
ruby extconf.rb script. I have to replace it with the pkg-config.exe
from the gtk+ website. It is really wasted a lot of my time to wonder
why the package can’t get compile, it also complaint that I don’t have
the gtk package.

Regards,
Shin Guey