[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DotGNU]'best damned development environment'
From: |
S11001001 |
Subject: |
[DotGNU]'best damned development environment' |
Date: |
Thu, 31 Jan 2002 15:49:18 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.7+) Gecko/20020106 |
Rather unfortunately, and going against usual GNU practice. I believe that this
project will have to provide some sort of integrated development.
The principal reason for this is to get people to use the GNU build style
(autoconf, automake, libtool, texinfo, ...) that, while powerful, usually
requires much extra learning time. These tools, properly used, can
significantly add to the portability of the build process (obviously, the
portability of the produced programs will not be much of a problem ;), but once
again, their use can become complex, and many people are not using these tools
to their fullest, simply because of this.
My idea for this, far from producing one ridiculous monolithic program,
consists of providing various pieces of X software (GTK/FLTK/Qt as the library)
that make using the GNU tools much easier. These processes, if they need to use
eachother, can use more creative ways of invocation and communication.
Also, it needs to be as simple as possible for command-line hackers, or just
those who don't want the DE, to use the GNU build environment.
Some suggestions for this software:
-is support for non-GNU absolutely required? answer me
-graphical debugger (with hooks to GDB?)
-project file manager, that handles generation of configure.in and various
Makefile.am files automagically (shouldn't be too hard :)
-NOTE: this may require actually changing autoconf and automake, or more likely
providing m4 macros that deal with cscc, csdoc, pnetlib, and whatever else is
required.
-tutorials/reference manuals for the various combinations of language/library
-an EMACS major mode for linking directly to manual spots (hit a function and
it looks it up in the standard library, then displays that in the info
program). Why? because writing another text editor to support it would be
ridiculous. However, this might not work out, in which case, text editor!
-documentation/manual tools, for WYSIWYG writing in texinfo format,
autogeneration of info documentation...this, I believe, is very important,
because most free software seems to be in constant need of documentation. And I
want those who will actually produce this to have a nice time with it (like me :).
--
Seriously, the way I did this was by using a special /sbin/loader binary
with debugging hooks that I made ("dd" is your friend: binary editors
are for wimps).
-- Linus Torvalds, in an article on a dnserver
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [DotGNU]'best damned development environment',
S11001001 <=