Re: Help packaging the latest pidgin.

2008/2/1, Neil Munro <[email protected]>:
> Ok so I have looked at the lb-window.c for the correct version of the
> program and have attached what I have done so far. The website shows me an
> example of what I should alter, however I found some things in the code I
> THINK look like they may also need patching, if they don't fine, but here's
> an example of one of the instances:
>
>     piece = gdk_pixbuf_new_from_file_at_scale (IMAGEDIR
> "/lb-middle.png",
>                            width, height,
>                            FALSE,
>                            NULL);
>
> The way I am thinking is that it should look like this:
>
>     piece = gdk_pixbuf_new_from_file_at_scale(
> g_build_filename( IMAGEDIR, "lb-middle.png", NULL ),
>                            width, height,
>                            FALSE,
>                            NULL);
>

Yes and no :)

Yes, it needs changing, but you'r change suggestion is incorrect. You
see, IMAGEDIR is a string constant, determined at compile time. You
want to change it to something that is determined at runtime (i.e.
using binreloc).

So the correct way would be:
    /* imagedir is of type gchar* and was initialized somewhere else,
by calling gbr_find_datadir and adding /images/ or somthing to it. */
    piece = gdk_pixbuf_new_from_file_at_scale( g_build_filename(
imagedir, "lb-middle.png", NULL ),
                           width, height,
                           FALSE,
                           NULL);
Also note that you are leaking memory here. g_build_filename expects
the return value to be free'd by the caller, which you don't do. If
this code is run several times, it could be a problem.

> I'm not sure though, but I think it's obvious WHY I think it needs changing.
> Also further reading on I have created the glib'd binreloc c and h files and
> moved them into /src in the gnome-launch-box directory, however I'm not
> entirely sure where to stick them, I downloaded the patch file to see if it
> could be of help, and while it gave me some ideas, I realize if I am to
> build pidgin, I won't have the liberty of looking at someone else's patch so
> I try not to rely on it.

> Also with regards to the tutorial
>
> " Grab binreloc from autopackage CVS, then run the generate.pl script. In
> this instance, we want the glib-ized version not the raw C version so pass
> "glib" as a parameter. It'll output two files: binreloc.c and binreloc.h.
> Add them to Makefile.am and re-run autogen, and now it's integrated with our
> project."

No, apparently they don't have an autogen script. Just run "autoconf"
(if you change configure.ac) and "automake" if you modifify
Makefile.am

> There is no autogen.sh file, so I had to fall back upon configure to see if
> it would work, not sure if you wanna change the tutorial to reflect this or
> not. Configure seems to run cleanly though.

See above, you need to call autoconf and/or automake if you change
Makefile.am and configure.ac.

> What do I do with this code?
>
> static gchar *imagedir;
>
> /* will be called automatically before main() */
> static void __attribute__((constructor))
> locate_image_dir ()
> {
>  if (gbr_init (NULL))
>
>  imagedir = g_build_filename (gbr_find_data_dir (DATADIR), "lb", "images",
> NULL);
>  else
>  imagedir = DATADIR "/lb/images";
> }
>
> It's not clear what I am supposed to do with it. It reads "Now we just
> change "IMAGEDIR" to "imagedir" in the
>
> window_pixbuf_fill_corner function and we're done. Let's test it!" I imagine
> that I stick that function at the top
> of the file and the change from IMAGEDIR to imagedir is the magic that glues
> all this together?

imagedir (lowercase) is a variable calculated at runtime. IMAGEDIR
(uppercase) is a constant calculated at compile time.

It doesn't matter where you put that code, as the __attribute__
(constructor) thing will make sure that it gets called before any
other function (as long as gcc is used to compile at least).

-Isak

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]