[Gtk-sharp-list] New (stupid) application :)
Thu, 13 Nov 2003 20:11:48 -0500
On Thu, 2003-11-13 at 04:02, Philip Van Hoof wrote:
> 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.
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.
> 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
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
> 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
> 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
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.