Some random thoughs and questions on the future of GNUstep

[Nikolaus Waxweiler]

Hi all,

here are some things that cross my mind every now and then. I'd like
to know what you think of them. Also, note that these are just ideas
-- nothing has been done yet except some minor tinkering with CMake
and there's no guaranty that there will be more. Yes, I know that code
says more than a thousand concepts :O



Adopting CMake (or better: Replacing GNUstep Make)
--------------------------------------------------

CMake is a cross-platform generator of Make files/project files. This
means that it will take a CMakeLists.txt file with build instructions
in it and turn it into a file readable by make (many Unixes), KDevelop
(Unix), XCode (Mac OS X), and Visual Studio 6-8, Borland or NMake
(Windows) and such. In a way, this makes it similar to the Autotools
tool-chain employed by the GNU Build System (the one with the
./configure stuff going on). You might have heard of it already, KDE
uses/will use it as the building tool for KDE 4.

Now, why CMake when we already have got GNUstep Make?  First, I must
admit that I have not used CMake extensively -- barely at all,
actually.  There are a few reasons why I propose it anyway, apart from
a big project like KDE using it.  The general idea is to move away
 from homegrown reinventions of the wheel and letting others to that
work for you.  Some weeks ago, Fedor asked if someone wanted to take
on maintaining GNUstep Make and that's the problem: GNUstep Make is a
build system in its own right which needs to be maintained somehow.
The (obviously) smarter thing to would be to let others do the coding,
especially if that piece of software is their main development focus.
Sure, it's yet another external dependency, but read on.

- CMake is a replacement for the whole Autotools suite, yet rather
   simple and easy to learn and requires only a C++ compiler to be
   build. It includes various macros to find and use commonly used
   libraries or applications (OpenGL libs, JPEG/PNG libs, Qt libs,
   LaTeX, etc.) and more macros can be easily written and added.  I
   guess this will make it a bit easier to check for external
   dependencies compared to GNUstep Make.
- As mentioned on
   http://wiki.gnustep.org/index.php/Roadmap_to_Windows#Make, GNU make
   is very unixy. CMake generates files for Windows-native build tools,
   making Windows developers' lives a bit easier.  Building the core
   libraries on Windows might also be facilitated if we switch from
   Autotools.
- CMake works out dependencies of files automatically, so you can run
   several concurrent build processes ("make -j 4"). I heard there were
   problems in that area with GNUstep Make.
- It includes CPack, a tool for automatically packaging files to
   install (.tgz and such). It even supports generating installers for
   Windows and Mac OS X if I understand correctly:
   http://www.cmake.org/Wiki/CMake:Packaging_With_CPack.  This should
   fulfill wish #2 (and maybe #3?) on
   http://wiki.gnustep.org/index.php/GNUstep_wish_list.  Might be
   possible to extend it to fulfill #4.  AFAIK it's currently in beta,
   .rpm and .deb support will come later.
- It includes CTest, a tool for running tests and submitting the
   results: http://www.cmake.org/Wiki/CMake_Testing_With_CTest. This
   should make testing a bit easier, encouraging more people to run
   tests.
- A percentage display to show the progress and colorful output when
   using Makefiles :O

You can find an example here: http://www.cmake.org/HTML/Examples.html.

Also, this is a guess, but afaik building -base and -gui requires
-make to be installed first to have the main GNUstep directory
populated with the appropriate build files.  Would it be possible to
decouple that when switching from Autotools?  Instead of putting the
libs in the GNUstep hierarchy, they could be installed in the standard
locations of a given OS, e.g. the executable put in BINPATH, libraries
in /usr/local/lib and resources in /usr/local/share/<app or lib>/.  If
a random developer wanted to use -base for a project, he wouldn't have
to install the GNUstep core package and have an unnecessary directory
hierarchy sitting around on his HDD or on that of the user, a
psychological problem. There are some people working on this, see
https://gna.org/projects/sidestep/, but I haven't found a reference to
them in the GNUstep ML archives. Anybody ever heard of them :O?

Unfortunately, there are also some downsides.

- Yet another dependency.
- Currently, applications depend on GNUstep makefiles directly
   (Project Center/Manager and pbxbuild) or indirectly (everything that
   uses GNUstep Make to build) and would need to be readjusted or
   overhauled to support both.
- CMake doesn't come with GNUstep support.
- The wiki suggests that currently, there isn't much to help building
   stuff on Mac OS X, like apps and frameworks, because it's still an
   area of active discussion/tinkering.  If something eventually
   becomes available, it might be possible to adapt it to GNUstep, but
   I don't know how much can be reused, if at all.  I saw that some of
   the Mac OS X logic is encapsulated in the XCode file generator
   written in C++.. Well, otherwise, we can always switch to the
   conventions native to a given OS as mentioned. I got to tinker with
   this some more.
- Cross-platform builds might be difficult or even impossible, but I'm
   not sure.

In conclusion, I think that CMake might become a viable alternative to
GNUstep Make. Does anyone beg to differ? Better alternatives? Keep
GNUstep Make? I see that the SideStep people use Autotools and a
customized jam called gsjam...



Adopting Doxygen
----------------

Doxygen generates documentation from source files.
http://www.gnustep.org/resources/documentation/Developer/Tools/Reference/gsdoc.html
states that GSDoc was created because no other software made
documenting Objective-C source code easy. Now, the current version of
Doxygen does support Objective-C, though the default output might need
some tweaking. Aside from that, move away from homegrown reinventions
of the wheel, more features, more than a few people know it, etc.

The SideStep (and Etoile?) people and libFoundation already use
Doxygen. See http://libfoundation.opendarwin.org/docs/ for
libFoundation. To see how the GNUstep source tree documentation looks
like, first install Doxygen, then do:

   cd /tmp
   svn co svn://svn.gna.org/svn/sidestep/trunk sidestep
   cd sidestep
   <edit Doxyfile.in -> replace "@DOTDIR@" by the path containing the dot
    tool. If you don't have graphviz installed, set HAVE_DOT to NO
    instead. You can also use 'doxywizard <file>' to configure stuff.>
   doxygen Doxyfile.in

and wait for it to finish (it generates no output except warnings).



Update or Abandon the Application Database?
-------------------------------------------

The current application database kinda sucks. So does the small
collection of applications on the wiki and MJ Ray also pointed out
that it will become tedious to search for applications when more will
pop up. The choices I see:

- Update the current application database with a nicer look and some
   other features (compare with Freshmeat.com). I think it would be a
   good showcase of WebObjects. Include the source somewhere so others
   can use that as a starting point for their WO development.
- Put some more work in the wiki for a better index of apps.
- Drop that idea completely and link to an already established
   database for applications in general. If it supports tags, we could
   easily link to GNUstep apps only. Freshmeat?



Miscellaneous and Spontaneous Ideas
-----------------------------------

- Use Yen-Ju Chen's MyLibrary
   (http://unix.freshmeat.net/projects/mylibrary/) as the help center
   and the answer to Nextstep's Librarian. Applications install their
   help files where MyLibrary can find and index them and taadaa, you
   have a note keeping, help storing and things-of-your-choice indexing
   application all in one! The only thing that would be even better is
   an enhanced Spotlight clone to do all of the above on all platforms.
- Make a clone of Squeak's code browser and integrate StepTalk to
   clone Squeak's Workspace. I wonder why I haven't heard about these
   concepts outside the Smalltalk community, since this has the
   developer focus on programming rather than messing with files,
   e.g. no more synchronizing header files with the source files and so
   on.  Should also include a SCM service with support for CVS and SVN.
   A 1:1 copy of Squeak isn't possible, but an approximate is fine,
   too. This might warrant a page on the wiki for further elaboration
   and illustration. I'm working on it.
- Better integration into Gnome/KDE/Windows desktops: AppWrapper.app:
   A script of some sort that, once run, collects information about the
   user's preferences. Is Gnome, KDE or Windows running?  Which apps
   can handle which MIME types?  Which icons do they have? This
   information is saved in separate application bundles and
   make_services is run.  Documents for which there is no GNUstep app
   installed will fallback on Gnome/KDE/Windows alternatives and for
   other files, the user has the choice. Generated App bundles should
   be flagged to make updating of apps easier, e.g. when the user
   installs other apps.