Re: About compatibility in GNOME 2 (was Re: Compatibility stuff)



Emotions aside, I believe Perl followed this path to allow authors of
CPAN modules to include this one .h file that would do the magic necessary
to allow an XS module to compile with virtually no changes, regardless of
which version of perl it was being compiled for.

This .h file was, mainly because of demand, then included in both the
maintenance release of 5.004, and the development release of 5.005.

I can't for the life of me recall the name of this .h file, since I
haven't done this stuff in a long time, but it certainly wouldn't
be a "bad thing".

Martin: I suggest you do as (Havoc?) suggested. Created a separate .h
file, and tell application owners that "if you use my module, it will
significantly ease your ability to have it compile for both GTK 1.x,
and GTK 2.x." Then, when everybody demands it, and starts bugging the
official GTK maintenance and development branches, they can take up
your quest for you.

"This is so stupid, why should we have to include the .h file in our
application, when it could be provided to all!"

mark :-)

P.S. I like the idea of allowing 1.x to be "forwards compatible" at
     compile time. It makes maintenance of the application itself
     significantly easier.


On Fri, Mar 09, 2001 at 05:08:30PM +0100, Martin Baulig wrote:
> Havoc Pennington <hp redhat com> writes:
> > Any maintainer who accepts a patch to build against two GTK versions
> > is insane, even if the number of ifdefs is only 5. It's flat-out a bad
> > idea. Use a branch.
> > 
> > Re-read Owen's mail; typically the port to GTK 2 allows you to
> > simplify code a lot, or use new features in GTK 2. There's no point
> > porting to GTK 2 if you aren't going to use any GTK 2 features, which
> > you can't do if you continue to work with GTK 1.2.
> I think your "ignorance" here doesn't help the GNOME 2 platform at all.
> 
> Imagine this (P = potential GNOME 2 contributor, M = me):
> 
> P: "I want to help with porting to / testing GNOME 1.x application Foo to/on
>     the GNOME 2.0 platform, what can I do to help you ?"
> 
> M: "There's not much you do at the moment. Ask the maintainer of library
>     Bar which is required by Foo to branch it and to port it to GTK+ 2.0."
> 
> P: "But can't we make a set of patches for library Bar and tell people that
>     they must apply to patches to their copy of Bar if they want to try out
>     Foo on GNOME 2.0."
> 
> M: "Well, no. This doesn't work. The problem is that the GTK+ team refuses
>     to keep the number of changes that are required to port Bar to GTK+ 2.0
>     small."
> 
> P: "What do you mean by this ?"
> 
> M: "Well, first of all, if you port Bar to GTK+ 2.0, this'll change its code
>     at a couple hundreds of different locations cluttered up all over the
>     whole module. And when you're done with it, Bar won't work on GTK+ 1.2.x
>     anymore."
> 
> P: "Can't we rearrange Bar's code in a way that all these differences will
>     be in one source file so that we just need to provide a different version
>     of that file ?"
> 
> M: "No, that's impossible."
> 
> ....
> 
> -- 
> Martin Baulig
> martin gnome org (private)
> baulig suse de (work)
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

-- 
mark mielke cc/markm ncf ca/markm nortelnetworks com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]