Re: Problem in debugging GPS

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Martin Krischik <krischik@users.sourceforge.net> writes:
>> If you like, I can send you my changes.  I've not only added a patch
>> to the GPS sources themselves, but I've also rewritten the build
>> machinery in a drastically simplistic way, consisting of *one*
>> Makefile (the famous debian/rules) and *one* GNAT project file.  This
>> comes at the expense of some flexibility; these scripts are designed
>> to work on Debian and only on Debian.
>
> But they are probably easier to read the en automake/autoconf stuff.

Oh yes, by a wide margin.  They're also much less brittle and
sensitive to the installed versions of the autotools.  In fact, they
are not sentitive at all to the autotools, since they don't use them.

In GPS, I haven't been able to avoid building some parts of
SourceNavigator and Berkeley DB, which are both bundled in the
upstream tarball.  For these I still have to call configure and a
recursive make.

>> I also make heavy use of shared libraries.  My GPS uses not only
>> libgtkada.so.2.8.1, but also libtemplates_parser.so.10,
>> libgnatvsn.so.4.1, libgnatprj.so.4.1, and libpython2.4.so.1 (yes,
>> Python is enabled in the Debian build, even in GPS 2.1.0).  Thus, I
>> completely avoid the code duplication that AdaCore seem so fond of.
>
> I never understood that. And am always nagged AdaCore about it. But they
> allways mandated that is has to be that way and it would not work any other
> way...

Unfortunately, they seem to be correct as far as 4.0.0 is concerned.
2.1.0 works fine with my simple build scripts and no code duplication,
though.  Currently, I'm trying to port GPS 3.1.3 forward to using
GtkAda 2.8.1.  You can already see my unfinished work in the Monotone
database, under the branch org.debian.gnat-gps.3.1.3.  The branch
org.debian.gnat-gps contains the completedstuff for 4.0.0; maybe you
or someone else could try and replicate the crash I experience?

> Up until I deleted my .gkt* and .gnome files any GTK+ application started by
> root crashed. Before you ask: vim is gtk+.

I never start applications as root.  Except for apt-get and aptitude :)

> For my main user user Gtk+ applications crash when opening a menu. But only
> when they where started from an icon. They work fine when started from an
> terminal window. ?!?!
>
> And if I start gnome-control-center beforehand the applications look all
> different as when I don't.
>
> Mind you I use KDE as desktop. But then: KDE applications never make such a
> fuss - even when started under a GNOME desktop. It is just that Gtk/GNOME
> is such a "Mimose" as we would say in Germany (Mimose: a flower which dies
> quickly when not treated to absolute perfection).

I use IceWM as my window manager.  No gnome, no KDE.  I occasionally
use GTK+ applications (Galeon, GPS, The GIMP) but most often, just
emacs and xterm.  At one point, for weeks on end I even ran with no X
at all; just emacs in full-screen text mode.  I stopped doing that
when I had to test GPS :)

>> You can get the Debian scripts and patches from my Monotone server on
>> Ada-France, if you want.  The reasons why I did not join the GNU Ada
>> project on SourceForge are because (a) I dislike Subversion, (b) the
>> Debian patches are older and much more extensive than the ones you
>> have, and (c) the build machineries mandated by the package managers
>> (RPM vs. DPKG) are radically different; so, merging the Debian patches
>> and GNU Ada would be quite a lot of work.  I'm not against it, though.
>
> Ok for (a) and (b) - but for (c): RPM is just one option. The Solaris
> maintainer create tar-balls. For MinGW I too have tried tar-balls and I
> have created quite a well working RPM-Spec to Tarball-Bash converter. Only
> MinGW on its own does not compile at all. Even Arno mentioned once that
> AdaCore uses cygwin for automake/autoconf etc.pp. So my current hopes are
> on an MinGW/Cygwin combo for MS-Windows.

I've standardised the way I make my Debian packages, especially GPS,
into two directories: debian/ and patches/.  It would be quite easy
for you to use patches/; but less easy to use debian/.  If you would
like to replicate all of that into your Subversion repo, be my guest
:)

-- 
Ludovic Brenta.