This is the mail archive of the
insight@sourceware.org
mailing list for the Insight project.
RE: Is the project still alive ?
- From: "Patrick Monnerat" <Patrick dot Monnerat at datasphere dot ch>
- To: "Keith Seitz" <keiths at redhat dot com>, <insight at sourceware dot org>
- Date: Thu, 26 Jun 2014 12:15:16 +0200
- Subject: RE: Is the project still alive ?
- Authentication-results: sourceware.org; auth=none
- References: <AB5E58B87EB73C46A38073D8F459F113D9FEA0 at dataspheresrv01> <53AB5285 dot 3020909 at redhat dot com>
Keith Seitz wrote:
> Hi, Patrick,
Hi Keith,
Thanks for your reply.
> I've been struggling with this very question for about a year now. It
isn't really clear to me that EOLing Insight would affect more than a
handful of people, and there are alternatives out there (Nemevier,
Eclipse-based standalone, QtCreator, Code::Blocks, ...).
I do not have statistics about use and installation count in Fedora, but
I received some crash reports and I can imagine some people are still
interested in insight in the Fedora community.
> A GIT repository exists, but I have not yet pushed it to sourceware.
Well, I saw sourceware git repo was empty and yesterday I started to try
to build a local git repo, using submodules. I hope we don't do the same
thing...
> When I last played with this, I wasn't very pleased by the direction
it was going. It was essentially a clone of the gdb repo with the
insight/libgui bits thrown in. Yuck. [If anyone has any better ideas,
I'm all eyes/ears.]
Submodules may help, but not completely: we cannot create the exact dir
structure as the CVS config did with git. In addition, gdbtk was part of
the "real" gdb directory and dropped out for the "gdb" checkout. With
the binutils-gdb git repo, we are in the opposite case.
I think migration to git can be done 2 ways:
1) Use submodules, then a rootdir script to "compose" the current dir
structure in a subdirectory.
2) Reorganize the Makefiles to have the gdbtk directory outside of gdb.
IMHO, 2) is more elegant, but harder to perform.
I tried yesterday solution 1), but I'm not happy either.
> At one time, my immediate for goal for the project was a slight/small
"reboot":
> 1) create GIT repo [created, not published, not happy with it]
> 2) NO in-tree Tcl, Tk, Itcl, Itk, iwidgets, etc. All must be provided
by the platform [or maybe on an auxiliary branch?]
> 3) Remove dependency on/prune libgui [TkTable is particularly
troubling]
> 4) Linux-only first "release"; cygwin using X and mingw to follow
> 5) Remove all the Foundry/Code Fusion junk from the tree and
simplify/audit the codebase.
> 6) Formalize and make "regular" snapshots/updates/releases
In my tentative, tcl/tk/itcl/itk are submodules from
github.com/tcklk/... And iwidgets (that is no longer within the itk
tree) is a snapshot since it is not kept in a git repo (using fossil). I
wanted to keep these bundles for the official insight repo, since
sourceware projects mostly seems "self-contained". But dropping the
bundles is OK for my one use. What about other users?
> I've toyed with jumping straight to a rewrite based on Tom Tromey's
python-based efforts, but it is still unclear whether that would work
well (enough?) on all the platforms I care about (Linux, MinGW, Cygwin).
That notwithstanding, I had convinced myself that I would need a
stop-gap solution until a rewrite was sufficiently advanced to be
useful.
You mean you want to drop (i)tcl/tk and use python? This would be a
great job, but would probably spend a long time before we have a running
version. This will also be the death of the present version, since no
update effort to the tcl/tk version will be done in the meantime. In
this case, I'd better EOL the Fedora package and re-emerge it when
Python version will be available.
> In the end, a part of me still believes that there is an audience for
Insight or something insight-like, i.e., a lightweight, *fast*, non-MI
GUI for gdb.
We're 100% OK on that :-)
Tell me if I can help.
Cheers,
Patrick