[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getting started writing desktop applications

From: Barry Fishman
Subject: Re: getting started writing desktop applications
Date: Wed, 20 Jul 2016 12:01:52 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

On 2016-07-18 12:52:24 +08, Nala Ginrut wrote:
> I happened to try guile-gnome few days ago, seems not workable with
> 2.1, I'm using the latest master. Anyone ever tried it?

Yes, with the same bad results.  It is hard for me to tell where the
issue lies, since many of its dependent packages fail their self tests,
although work with my own simple tests.

The whole autoreconf setup for added modules seems to get broken with
every development releases.  Some packages seem to require multiple
reconfigs before they build.  Tests break with errors like not being
able to exec "/bin/sh", which I can never seem to trace back though the
garbage Makefiles the autoconf system generates.  When I do things with
my own driver Guile scripts the test code seems to work just fine.

I don't understand why Guile modules use such a patchy environment when
if you are building them you know there is a perfectly good Guile
already built, which better understands it own build environment, and
can find out what it needs to know with pkg-config and if really
necessary, building its own C tests.  Simple packages like guile-lib now
fail tests even without need for C tests.

Yes, work has been put into autoconf to make it very powerful, but like
most pure macro based environments the output is fragile, and almost
unreadable by most mortals.  I have on occasions been able to fix some
configure setup, but usually at the expense of a great deal of time (and
frustration), and inability to test it on all the required environments,
or even understand what the required environments are.  I don't use
MS-Windows, Atari, or some long obsolete Unix like systems.  Knowledge
of such should really be part of the tools, not part of the developers
working knowledge.

For me, the hardest issue in Guile updates seems to be patching all the
autoconf environments of other peoples packages, most of which I needed to
wait for some more skilled hacker to come along and decide to do it.  I
have no problems with fixes to the actual Guile code, on the rare cases
such problems exist.

I love Guile. It does a great job of extending, sustaining, and
documenting, its *embedded* functionality, but user contributions are
far too difficult to export and integrate.  The solution should not be
to integrate everything, but make adding new user contributions easier.
Something like or (even better) Haskell Cabal/Hackage.  *Not*
something like Emacs packages.

Barry Fishman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]