[Gtk-sharp-list] SVN trunk branch
Jeroen Zwartepoorte <email@example.com>
Tue May 10 10:54:29 EDT 2005
Thanks for the info. I have a couple of questions though:
"Note, 1.9.x and 2.5.x are not parallel installable and there are no
plans to make them so.": Does this mean that you plan to drop/not
make a final release of the 1.9 version and move to 2.5?
Why not release 2.0 now and move HEAD to 2.5? In other words: what
issues remain until 2.0 can be released?
What's the status (in your view) of the gnome-vfs bindings? The one
serious bug i saw in bugzilla is from Jorn and we both can't reproduce
his problem (waiting on info from him until i can debug it further).
p.s. Are you going to guadec?
On 5/9/05, Mike Kestner <firstname.lastname@example.org> wrote:
> Anyone using release tarballs or packages for Gtk# need not read
> further. This message is intended for people who are building Gtk# from
> the subversion repository to track the bleeding edge.
> The trunk branch in svn now supports both 1.9.x and 2.5.x release lines.
> Since there are more similarities than differences between these two
> bindings, and they are both unstable, I decided to produce them both
> from the same branch instead of having to cross commit virtually every
> patch to two branches.
> This has introduced a minor change to the current svn build process.
> Instead of the usual:
> autogen.sh && make && make install
> I have introduced a pair of bootstrap scripts to set your environment
> for either 2.4 or 2.6 bindings. If you do:
> bootstrap && make && make install
> You get a 2.5.x release installed. bootstrap takes the same arguments
> as autogen and configure did, so:
> bootstrap --prefix=3D/opt/foo && make && make install
> Is the way to get a prefixed installation.
> If you want to build the 1.9.x release line, there is a bootstrap-2.4
> command to set trunk up for it. So you do:
> bootstrap-2.4 --prefix=3D/opt/foo && make && make install
> To get 2.4 bindings and a 1.9.x version.
> Note, 1.9.x and 2.5.x are not parallel installable and there are no
> plans to make them so. We are just continuing to produce a parallel set
> of unstable 2.4 binding releases to the current 2.5.x development
> release to support people who want to use an unstable series on
> platforms that don't yet support Gtk+ 2.6.
> Before I get a lot of "Why don't you do this?" messages (especially from
> you Ben), I'll try to explain my rational for the bootstrap process.
> Q: Why not have configure detect the Gtk+ version and build the
> appropriate binding?
> A: Because I want to be able to distcheck tarballs for each version that
> contain only the necessary files for that specific Gtk+ version.
> Q: Why don't you have autogen detect which version of Gtk is installed
> A: Because I want to be able to compile/test both branches on a single
> machine that has 2.6 installed.
> Q: Why not have a single autogen script with an option for selecting the
> binding version?
> A: Because I'm lazy and the two bootstrap script approach was easier.
> Besides, I don't think bootstrap-2.4 ... is any less usable than
> autogen.sh --version=3D2.4. However, if somebody wanted to spend the tim=
> to make a single autogen script that defaulted to the installed Gtk+
> version but also allowed overriding of the choice, I am accepting
> patches. I've personally got more important fish to fry though.
> Mike Kestner <email@example.com>
> Gtk-sharp-list maillist - Gtkfirstname.lastname@example.org
More information about the Gtk-sharp-list