Compiling on Fedora Rawhide

[Neil Williams]

On Friday 14 October 2005 7:16 pm, Chris Shoemaker wrote:
> > These can
> > (realistically) only expect to use the goffice external libraries.
>
> Why is it unrealistic to expect all distributions to use the
> internal library?

Because the internal library is insufficient. If I could use lib/goffice, I 
would. Without question, I would never have even looked at the external 
libraries, they weren't installed originally. However, ever since lib/goffice 
was put into G2, my Debian build has been broken again and again by changes 
in the dependent libraries. I'm not sure if libgsf is the only one.

> > Once
> > goffice-dev is installed, gnucash will compile using that code.
>
> Are you sure?  Is that supposed to happen?

That's the only way I can compile G2. With goffice-dev (or equivalent) 
installed, G2 builds using the conditional build instructions that I tweaked 
in the last commit. That is why I patched the file in src/gnome-utils.

> > Personally, I don't want G2 to only have functional graphing capabilities
> > on FC3 and similarly "old" distributions.
>
> Huh?  How would that happen?

Because the internal code relies on other libraries that are NOT currently 
packaged and which are not compatible with the snapshot.

The packaged goffice binaries use an API that is sufficiently different that 
although I get it to compile, it does not actually display any pie charts or 
bar charts.

FC3 does, Debian cannot. I get a simple error message in place of the chart. 
G2 won't get into Debian like that.

I haven't yet tested a method of bridging the gap in one area:

+#ifndef HAVE_GOFFICE
   gog_object_set_pos(tmp, GOG_POSITION_N | GOG_POSITION_ALIGN_START);
+#endif

i.e. when HAVE_GOFFICE is defined, no object_pos is set. I haven't yet had 
time to look at the alternative function call suggested earlier this week.

> > I think we need to embrace the
> > released goffice libraries, try to track the changes and get into sync
> > with the evolving goffice API.
>
> Did you see Josh's post on this topic?

Yes. However, I cannot downgrade libgsf sufficiently to build the internal 
code because of other dependencies.

I have libgsf-1 1.12.3-4 - the only version available without going all the 
way back to stable (KDE 3.2), g-wrap 1.3 and --disable-error-on-warning 
again.

> > If the API
> > difference is small between 0.1.0 and our copy, then I think the "right"
> > fix is to conditionalize our gnc-html-graph-gog.c to work with either.

That is my favoured approach and the reason behind my changes to that file.

> > If not, then I think the right fix is to specifically, conditionally use
> > the 10-argument version of that libgsf macro, but to only use our
> > internal libgoffice copy / never use the external goffice.

There are more changes than just the GSF_CLASS_FULL macro, 

+#ifdef HAVE_GOFFICE
+  labelData = go_data_vector_str_new((char const * const *)labels, datasize, 
NULL);
+#else
   labelData = go_data_vector_str_new((char const * const *)labels, datasize);
+#endif

+#ifdef HAVE_GOFFICE
+  sliceData = go_data_vector_val_new(data, datasize, NULL);
+#else
   sliceData = go_data_vector_val_new(data, datasize);
+#endif

+#ifdef HAVE_GOFFICE
+    g_object_set (G_OBJECT(action), "is_important", TRUE, FALSE, NULL);
+#else
     g_object_set (G_OBJECT(action), "is_important", TRUE, FALSE);
+#endif

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051014/7a64d26e/attachment.bin