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. _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
