[Gtk-sharp-list] New (stupid) application :)

[Jonathan Pryor]

Inline...

On Thu, 2003-11-13 at 04:02, Philip Van Hoof wrote:
<snip/>
> 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
> it.
> 
> 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.

Take a look at the mono-tools CVS repository.  It marries the auto*
tools with Makefile-based projects, such as type-reflector.

The autoconf script is fairly simple & straightforward, allowing people
to specify --prefix & other common options, and these options are
forwarded to the Makefiles of sub-directories, allowing things to fit
together reasonably coherently.

<snip/>
> 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).

The auto* tools were *designed* for C and C++ modules, so that isn't
surprising.  C/C++ code *needs* the auto* tools, just to bring some
sanity to the world of #ifdef code and portability among platforms.

Managed code shouldn't have to deal with that, though.  That's what
managed code is for -- to abstract out the platform-specific details.

Of course, if you start getting platform-specific managed code (such as
heavy P/Invoke use, etc.), the auto* tools will be useful.  But I don't
think we want to encourage heavy use of platform-specific code.

So I would vote for either Makefiles or NAnt.

> 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?!

C/C++ apps have the following simple pattern:

	./configure && make && make install

We could instead have:

	make && make install

or

	nant && nant install

So I don't see a major difference, except possibly for common configure
options, such as --prefix.  But this can be done with minimal use of the
auto* tools (again, see mono-tools).

> So.. My suggestion is
> 
> Or we create a new sledge hammer to build .NET applications in a platform
> independent way

I suppose we could try to clone msbuild,  whenever that becomes
available.

> Or we all start yelling: use Nant (which looks like a good option to me)

A nice option, but it does increase the dependencies.  You need NAnt
installed in order to build the apps.

> Or we all start yelling: Create your custom makefiles

Possible (I've done this), but people seem to hate make for some
reason...

> Or we all start yelling: Use auto* in this ... way

This is a bad idea.  Just my opinion.

> 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. 

Distribute in .zip files? :-)

Installation would be simple: unzip & move.

(Unless, of course, you make use of shared assemblies, but I suspect
most apps require them.  Besides, mono doesn't have a GAC yet, so we
can't really support shared assemblies properly anyway.)

> How I build buildscripts so that
> packagers can easily build packages that depend on a .NET environment and
> Gtk-Sharp.

This could use a more detailed answer.  Again, I'll suggest mono-tools,
but I'm sure there are better ways to do it.

> 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)?

I'd like an answer to this as well.

 - Jon