Re: SigC::, sigc::, Build Environment, and Main Event Loop Update from deeply-nested recursive functions.

[Ed Leaver <eleaver sterlingseismic com>]

On Fri, 2006-01-27 at 04:17, Murray Cumming wrote:
> [snip]
> > 2. SigC::, sigc::, and My 0wn Turgid Build Environent. Actually, I had
> > hoped to post the above Event Loop update solution ten days ago, as it
> > only took a few hours to implement. Unfortunately, there was another
> > more pressing item in my exchange with Murray that I wished to address
> > first. This had to do with an (ad)mixture of SigC:: and sigc::
> > namespaces in my code, and the resulting confusion that ensued when I
> > coded signals. Glade generates code that uses SigC::
>
> That seems unlikely, unless you only have libsigc++ 1.2. But anyway,
> problems with glademm code generation are for the glademm-list. It's a
> separate project that I don't particularly recommend. Future versions of
> Glade will remove the code-generation feature from the Glade application.

I can understand why you might not particularly recommend Glade. But at the time I started this project, Bakery was in (or appeared to be in) a moderately-alpha state, Glade was "mature" (I use the term loosely), Rikke Guiles had a nice tutorial, and it worked. Glade still does work. Doesn't necessarily mean I'll use it for future projects, however.  
> [snip]
> > But don't Go There: you're needed here at home. Besides, this one too is
> > solved: for various reasons far beyond my personal control, my target
> > platform is plain vanilla completely un-updated Red Hat Linux 7.3 and,
> > due to an inability to find an updated Render package, I had prevented
> > myself from doing a complete upgrade of my build environment to
> > gtk+/gtkmm-2.4. I was seemingly stuck at glib-2.3.6, glibmm-2.3.8,
> > gtk+-2.2.4, and gtkmm-2.2.12.
>
> glibmm-2.3.8 and gtkmm-2.2.12 in no way interact together. If you have
> gtkmm-2.0 installed then you also have glibmm 2.2 installed. You will have
> massive problems if you try to include and link to both the gtkmm-2.0 and
> gtkmm-2.4 APIs (likewise glibmm-2.0 and glibmm-2.4). I'm surprised that
> the linker allowed this.

That's fine: you're human and are allowed to be surprised

 But no, I never had more than one version of any library except libsigc++ present in my build at any one time. What I did have was combinations of glib/glibmm-2.3 (or 2.4) and their requisite libsigc++2.0, together with older gtk+/gtkmm-2.2 and their requisite libsigc++-1.2. Now that did eventually create problems, apparently with libsigc++, but at run-time, not during compile or link. But better late than never: gobject.c did trap it, which is why I (re) started my build investigation, and btw contacted you. But the surprising thing is, the code actually worked. (Sorta like the proverbial Dancing Bear...) 
> > The first two required libsigc++-2.0.16,
> > whilst the latter needed libsigc++-1.2.5. Which is why the old SigC::
> > namespace was visible in my build. And I didn't know any better than not
> > to use it. But I couldn't get rid of libsigc++-1.2.x unless I could
> > upgrade to gtk+-2.4.x/gtkmm-2.4.x, and I couldn't do that unless I had
> > updated the Render header files, which I thought were part of the system
> > X11/XFree86 package, which I thought I couldn't require my intended
> > customers to upgrade, so I thought I was stuck at gtk+/gtkmm-2.2.x.
> >
> >   Only I thought wrong. About Render I mean. I finally found a suitable
> > render-0.8 tarball at a suitably obscure SGI (bless 'em) ftp site,
> > upgraded to glib-2.6.6/glibmm-2.6.1, gtk+-2.6.10/gtkmm-2.6.5,
> > libglade/libglademm-2.4.2, and glade-2.6.8/glademm-2.6.0, all on stock
> > vanilla totally un-upgraded Red Hat Linux 7.3 and without
> > libsigc++-1.2.anything. As coded on a closed-course by a "professional"
> > systems programmer: don't try these stunts at home...
>
> This sounds like a catastrophy. This is no way to install software. If you
> can't easily get the new software onto RedHat 7.3 then use the software
> tha that you can easily get onto it.

Actually it is a way to install software. And not that hard. Particularly after my recent discovery (whilst I was tracking down render-0.8) of the gnome.org page that lists the libraries in each official Gnome release. I figure as long as I stick to that list, and their micro-version number updates, I should be OK. Pkgconfig is my friend. (Famous last words.) That said, an alert observer (e.g. yourself) might opine that still is not exactly what I have done, as at present I'm mixing gtk+/gtkmm-2.6 with glib/glibmm-2.4. To which I'll cheerfully admit. And  I fully intend to re-build against gtk+-2.4.14/gtkmm-2.4.11 this weekend: I had that combination working briefly earlier; I went on to gtk+/gtkmm-2.6 only to test my luck. Your concern there is admittedly well-placed.

As for going back to the stock RH 7.3 Gnome development environment, I certainly can see your position there as a maintainer. You have both my sympathy and my condolences. But as a developer... well yes, I do have some concern loading new freetype, fontconfig, render, xrender, and xft libraries onto such an old dog of an OS. But I put them all (i.e., all my gnome-specific build libraries, all 17 of them) in their own separate /opt/osi-ir/ vendor area, so its not as though I'm deliberately stepping on system libraries.  Compilation is clean. And if there is a runtime conflict with system code, I have yet to see it. 

Which doesn't mean it will never happen. The proof will come when I try to install my application (and its libraries) on disparate systems. Beta testing, you know. Then I will know. Meantime, the font improvements alone in gtk+-2.4 are a large disincentive to going back. Then there is reverting all my newly-coded libsigc++-2.0 usage back to libsigc++1.2. Not that it would be impossible to do so, just that I don't yet see the point. (But ask me again come June...)
> >   (But if you've read thus far and think you really must, reply to this
> > and I'll see if I can post my library build script.)
> >
> >   The upshot of removing libsigc++1.2.x was that SigC:: namespace became
> > invisible outside the Glade-generated code (I still don't know why it is
> > visible even there -- possibly something todo with #include
> > <sigc++/compatibility.h>:) and I was mercifully forced to convert all my
> > own signal stuff to sigc:: after which I found I no longer needed to
> > derive my C_RowSignal class from Glib::Object, and those sniveling
> > start-up objections from gobject.c magically disappeared.
>
> glademm code generation.
Ah. "But you're too personally involved to be objective."

(See "Venus on the Half-Shell", by Kilgore Trout, as ghost-written by Phillip Jose Farmer)

> >   The immoral being that on gtkmm-list one can learn something new
> >   every day.
> >
> >   On a *really* bad day, *two* new things...
> >
> > 3. One of the new things I'd like to learn today is this: the odd
> > documentation frustration notwithstanding, in general I've been *very*
> > impressed with the overall code quality of Gtk+/Gtkmm. As a pleasant if
> > unexpected surprise, in two and a half years of development this archive
> > application the only bugs I've been able to positively identify have
> > been my
> > own. Yeah, I know that gtk+/gtkmm has some some, but I've tried hard (if
> > unsuccessfully) to keep my particular application simple so as not to
> > exercise them. So I'm personally quite pleased. However, I have a
> > partner and colleague who has personal friends at Trolltech, and while
> > never having actually coded with Qt, is understandably biased in that
> > direction. He inquires whether commercial support is available for
> > Gtk+/Gtkmm. It it?
>
> Gladly. See the bottom of this page:
> http://www.gtkmm.org/commercial_support.shtml

Thanks!
     Ed Leaver

> I'm sure there's a few more people and companies who would like to be on
> that list.
>
> Murray Cumming
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com