Re: giomm in svn

["Marko Anastasov" <marko anastasov gmail com>]

On Dec 20, 2007 7:51 AM, Murray Cumming <murrayc murrayc com> wrote:
>
> On Thu, 2007-12-20 at 00:54 +0100, Marko Anastasov wrote:
>
> > On Dec 17, 2007 2:15 PM, Marko Anastasov <marko anastasov gmail com> wrote:
> > > I will move the code later in the evening or tomorrow.
> >
> > ... or the day after tomorrow. I haven't been home much hence the delay.
> >
> > An instant before adding the files to the repo and committing I realized
> > that instead of adding 36 new files to glib/src, it would probably be better
> > to set up a separate gio/ directory sub-tree and giomm module from the start.
> > What do you think?
>
> It's hard to decide between
> - saving some people from having to link to gio if they don't use it
> and
> - increasing load times by adding a library
>
> But we already wish that ustring was in its own library so I think this
> is probably the best idea.

I'm sorry, but I need some help here and I don't think days should just pass
if I don't know what to try next...

So I've been trying to create the gio/ module. The problem I cannot solve atm
is caused by the Makefile.am in the private/ directory. Which is quite strange
as it is practically the same in all *mm projects. I tried creating
this sub-tree
by hand, copying it from gnomemm/giomm, and finally just copying the gdk
subtree and replacing the strings. The error is always:

automake: cannot open <
gio/giomm/private/../src/Makefile_list_of_hg.am_fragment: No such file
or directory

while the file contains a line

include $(srcdir)/../../src/Makefile_list_of_hg.am_fragment
(note "/../../" vs "/../")

I have also tried hardcoding the path but then there is a message about
recursive (infinite) inclusion. There is no "debugging" information in those
error messages, so I don't really know how to fix it.

So if someone could guess the solution or maybe even create a dummy
module with just asyncresult.hg (the rest need some modifications which
have been waiting on my hdd) I would be very grateful.

Btw afaik giomm being a separate module implies that the namespace
shall stay Gio, as it has been so far. I think that it its' version should
be the same as glibmm's. But perhaps the soversion could be separately
defined?

    Marko