[Gtk-sharp-list] New (stupid) application :)
Philip Van Hoof
Thu, 13 Nov 2003 10:02:08 +0100
> -----Original Message-----
> From: Jonathan Pryor [mailto:firstname.lastname@example.org]
> Sent: Thursday, November 13, 2003 3:22 AM
> To: email@example.com
> Cc: Philip Van Hoof; firstname.lastname@example.org
> Subject: Re: [Gtk-sharp-list] New (stupid) application :)
> I fail to see how auto* makes packagers lives easier.
Agreed, I fail to see to same thing. However, most package maintainers tell
me that the scripts to build the application should have all types of
options and stuff, like the --prefix thing. And that all these fancy targets
(like distclean, clean, dist, distcheck, all, bla) should exist at all times
to make sure that they can support every Linux dist. and every version of
I am not a packager, I have no idea how to create a good package (I know +-
how a spec file looks like, but that's it). So I too fail to see that.
> Actually, that's an almost-lie. The one thing that auto* tools make
> easy is simple generation of the "make distcheck" target, which (in
> turn) requires the ability to place compiled binaries outside of the
> While somewhat useful, I don't think this is actually
> *required* by most people, and I certainly can't imagine it being required
> for packaging.
> (And yes, I've done packaging for the mono-tools CVS repository, to
> generate RPMs in a somewhat automated fashion. It required
> some support
> from type-reflector's Makefile, mostly supporting the
> "distdir" target,
> which makes it easy to make a .tar.gz from the source code,
> but nothing
> *required* the auto* tools.)
> > Maybe we could start a draft ?
> That would likely be useful, but it is also likely to suffer from
> opinion overload. :-)
> Mostly because there is no "one true answer."
If Gtk-Sharp wants to mature a little bit more, and if gtk-sharp as an
environments wants to become an option for Linux GNOME developers, then
"true answers" will have to be made for them who don't know any answer at
all. Auto* is probably the worst choice available. But it's a possibility
and accidently, everybody appears to be using it (at least, most if not all
C and C++ modules in cvs.gnome.org).
So in a way there is a common method for distributing buildscripts for C and
C++ applications. Packagers know about this method and if the creator of the
script follows some guidelines, creating packages becomes an easy task and
automated, I assume?!
So.. My suggestion is
Or we create a new sledge hammer to build .NET applications in a platform
Or we all start yelling: use Nant (which looks like a good option to me)
Or we all start yelling: Create your custom makefiles
Or we all start yelling: Use auto* in this ... way
As far as I know is Gtk-Sharp, as a programming environment, ready for real
life usage (agreed, there are some showstopping bugs, oh well). The things
that really keep stopping me are the questions like how I should distribute
my application in a Unix environment. How I build buildscripts so that
packagers can easily build packages that depend on a .NET environment and
Gtk-Sharp. How do I use po files for translations, and how do I make the
lives of the translators as easy as humanly possible (not all of them are
professionals, you know)?
IMHO the success of a environment, like Mono and Gtk-Sharp, does not only
depend on how good the language, the jitter and the bindings are. Also the
little things are required for a programmer to choose "Gtk-Sharp". It's
knowing those things that will make development go faster (and nobody likes
searching google to learn how to get something stupid like buildscripts
done, actually..I hate it).
Philip Van Hoof, Software Developer at Cronos
home: me at freax dot be
work: Philip dot VanHoof at Cronos dot Be