On Thu, 2007-12-27 at 12:41 -0500, Stuart Brorson wrote:
> >> PS. Why did intltoolize get introduced as a dependancy for gEDA/gaf?
> >
> > It is needed to translate the .desktop and mime type registrations. The
> > normal gettext framework doesn't do those type of files.
>
> Actually, I've been considering whining about the intltoolize stuff,
> but decided to keep a stiff upper lip. Now, however, I've been
> prompted to snivel and whine.
>
> I've been having a devil of a time building the stuff requiring
> intltoolize [1]. This includes gEDA/gaf as well as xgsch2pcb. The
> intltoolize stuff is very new, and pulls in lots of dependencies on my
> older devel boxen. Yes, this is not a problem for users, but it does
> make my life as a developer more difficult. :-(
Please list the dependencies which have caused problems. On my Ubuntu
box, it depends on:
automake1.7
file (to discover what type a file is I guess)
gettext
libxml-parser-perl (For translating XML files)
patch
perl (The build scripts use perl)
Of these, only libxml-parser-perl seems like it might be even remotely
"exotic". It is needed for translating XML files, such as the XDG mime
registrations.
> Is there any way to make the intltoolize stuff optional at the
> automake level? Or maybe forget about .desktop translations (and the
> .desktop stuff itself) for a while, until the stuff is more
> widespread?
It would be a lot of work for something which reduces our I18N support.
> It's kind of whacky that we require <= GTK-2.4, but then rely upon all
> these new whiz-bang features which are probably only a year or two
> old.
It is probably about time that we stopped adding lots of workaround code
to make us GTK 2.4 compatible. The main difference here, is that users
will have a particular version of GTK installed. Nothing stops them
installing intltool.
> It does make me think that we need to extend the dependency policy to
> exclude anything younger than two years, say.
> Opinions?
In my opinion, an arbitrary cutoff like this is far more likely to
stagnate and kill the project than the inclusion of any database behind
the scenes.
To stay "competitive", we need to work on new code (like cairo
rendering) now, not two years after everyone else is using it.
I've tried hard to limit breakage and build issues. I didn't _really_
want to include intltool - however I do believe it is the tool for the
job in this case.
> Stuart
>
> [1] And the desktop tools, and the DBUS stuff, and the pydbus module,
> and the .....
There is bound to be some teething trouble with new code, but do let me
know if there are particular problems, I do want to see them fixed.
I spoke to my friend who codes chip design software for a living.. they
don't have any external dependencies outside libc, and perhaps libx11.
(They ship everything else themselves).
I guess this approach would just mean we had lots lots more complex
software to build and install.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
