This is the mail archive of the insight@sourceware.org mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Is the project still alive ?


 
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]