The Workspace
With GNUstep you have great piece of software. It is the GNU implemention of the OpenStep standard once put forward by NeXT Computer Inc. and Sun Microsystems Inc. It provides you with a complete object oriented development environment to create portable applications.
This document is intended for users of the GNUstep system. The primary goal is towards software developers, but it can also be a valuable resource for those that just want to know more about the software they are using.
The GNUstep system will be explained from both a functional and an architectual perspective. The document also explains terms and conventions like Bundles, Frameworks and the services that can be expected to be present on your GNUstep system.
The GNUstep System Overview is meant as an introduction, where possible links will be provided to more indepth documentation.
2002 May 3:
Restartes working on this document. Made it comply with gnustep-back change.
2001 July 13:
DL: Edited the Makefile DESIGN document to get it up-to-date and to fit within this document.
2001 July 3:
DL: Updated GWorkspace images. Updated Windowing System section.
2001 June 25: Pre-release version
DL: Merged Gregory and mine documents to one.
2001 June 16: Initial version.
DL: Merged the previous User Guide and Administrators Guide to this document. Rewrote lots of pieces and created a lot of new ones.
Copyright (c) 2001 Dennis Leeuw & Gregory John Casamento.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover Texts being GNUstep System Overview, and with no Back-Cover Texts.
A copy of the license is available through the section entitled "GNU Free Documentation License".
This document is copyrighted according to the FSFs GNU Free Documentation License of which the most recent copy can be obtained from http://www.gnu.org/copyleft/fdl.html.
The following people have helped in making the document better, fixed errors and where so kind to be proofreaders:
Pascal Bourguignon
Peter Cooper
Robert E. Hartley
Special thanks
Ovidiu Predescu - For letting us use his Makefile Design document within this document
Apple, Mac, Macintosh, TrueType and Cocoa are trademarks of Apple Computer Inc.
Enterprise Objects, Enterprise Objects Framework, NeXT, Objective-C, Application Kit, Foundation Kit, Workspace Manager, NEXTSTEP and OpenStep are trademarks of NeXT Software Inc.
Java is a trademark of Sun Microsystems Inc.
PostScript and Display PostScript are trademarks of Adobe Systems Inc.
Windows and Microsoft are trademarks of Microsoft Corp.
GNUstep is the Free Software Foundations implementation of the OpenStep API once part of the NeXT development environment OPENSTEP. It is meant as an easy to use development environment based on object oriented programming techniques.
For a better understanding of the choices made a dive into the past is the best starting point.
When Steve Jobs left Apple Computers, Inc he started a new company called NeXT Computers , Inc. In 1988 the company released a computer called the NeXTCube with a new operating system called NeXTSTEP. In 1989 NeXTSTEP 1.0 saw the light of day.
Together with Sun Microsystems NeXT Computer teamed up to define a standard for a graphical development environment called OpenStep. And soon there after NeXT released its OPENSTEP system. Hope you noticed the difference between OpenStep (the standard) and OPENSTEP (the NeXT implementation of the standard). The difference is essential and a thing that often leads to confusion.
Due to financial trouble NeXT Computer changed its name to NeXT Software and stopped the hardware development. From then on they concentrated their resources to bring a development environment that was intended for a write once, compile everywhere, system.
In late 1996 NeXT was acquired by Apple Computer. Steve Jobs was made interim CEO of Apple shortly afterwards, replacing Gil Amelio. The new version of the operating system, Mac OS X, is an updated version of the OpenStep frameworks (now called Cocoa), with a Macintosh look and feel, on top of the latest version of the Mach kernel.
The GNU project had in the meantime picked up the specification and started developing their own implementation in 1995, with the intention to make it the default environment for the GNU operating system.
This is all very nice but what is in it for you, the user or developer? Well, GNUstep is going to make true what NeXT wanted OpenStep to be. A cross platform development environment. GNUstep can be used on various platforms: Linux, Windows, Solaris, BSD and more. This creates a platform independency. You do not have to worry about the actual operating system. You only have to use the beautiful graphical interface. And you never have to learn another one again.
Another nice thing about platform independancy is that when you want to use another operating system or a different computer you can take your favorite applications (programs) with you. There is no need to learn another text editor, just use the one you like: everywhere.
And the last big reason to use GNUstep is the benefit of the NeXT interface. The interface is designed with you in mind not the computer. That means it is easy, it's consistent. All work can be done with the least possible effort.
Every system has an interface to communicate with the user. It's the so called UI or GUI for Graphical User Interface. The main thing of the GUI is to provide you with a way to access the system. You should be able to access files, walk through directories and the like. GNUstep provides you with a tool called the Workspace that implements this functionality. Since GNUstep is an not a company, you get to choose the workspace manager you like. We have picked one to show you what you might expect of a workspace manager.
The Workspace
GNUstep reintroduces the NeXT style of user interface. Which means that the menu and the application are two different entities on your desktop. If you have worked with Microsoft products before this is probably a new concept, if you are familiar with the Macintosh you probably know this already, except that the look is somewhat different.
One window holds the program, which in this case is the File Viewer, while another one holds the menu associated with the application. The idea is to create an as consistent interface as possible and to provide as most flexibility as possible. You will find lots of examples throughout this document that will show you the truth of this.
You know the clutter you can get when several applications have open windows on you desktop. GNUstep solves a part of that problem in several ways.
First there is the menu. Only the menu of the application your are currently working with is shown. As soon as you click the window of another program the menu of that program appears and all others will disapear. That saves room.
Since the menu is a seperate identity and consistent throughout all GNUstep applications it is time to take a closer look at it. At the top you see the info item. Opening that you get more info about the application, there is info about who wrote it, the copright, the prefernces menu and access to the help system.
The file entry gives you access to all things that concerns file handling, open, close, new, etc.
Every menu has an edit section. This contains options used to copy, paste and otherwise modify selected objects.
We skip the disk, view and tools sections, cause those are GWorkspace specific. Services, Hide and Quit are however general parts of every menu. You'll see, the first three and last three are always there.
The Services menu item gives you access to programs that are helpers to this program. Imagine you have a mail application and receive a tar.gz attachment, which is a Unix archive of data that is zipped. A mail application doesn't know how to handle that, but a unpacker does, so the unpacker could be a helper application for mail and could be available through the Services menu item.
Selecting the Hide item causes the menu and all program associated windows to hide behind the program icon on the bottom of you desktop. Double clicking the icon puts everything back to where it was before.
And Quit..., yep it closes the application.
The menu can be placed where you find it convienient. Not a menu bar at the top of your screen (like Mac OS) or a menu in the application window (like Windows), just place it where you like. You could even drag sub-menus, like the Tools menu from its main menu and place it somewhere else.
A torn appart menu
But let us continue with the Workspace. There are more things that makes life better. The File Viewer consists of three parts. One is The Shelf, which is used to store often used applications, documents, links, etc. Just drag something from the Viewing area to the Shelf, release it and it sticks on the Shelf.
Below that there is the Icon path. This gives you a quick image of where you are within a directory tree. And offers you a quick patch back too. Just use the scroller to get back quickly where you came from.
And last you have the actual Viewing area. Here all files and directories are shown in the path. In our example you see a file listing with three colomns, but ofcourse this can be reduced or expanded with less or more colomns. But also you could choose to have an icon view or even a listing like on Unix systems. All is there for you to choose.
The Desktop
Next to the fact that you can store applications on the shelf there is a real place for adding often used programs and that is called the Dock. The most logical usage for the Shelf is storing often used directories and files so you can use the Dock for often used applications.
Apps docked are available across workspaces. But if you like to use certain applications on a certain workspace, like I have my Internet browser on one workspace and my graphics applications on another. This way I keep my screen as clean as possible. You could use the Fiend to hold your workspace specific Apps. So actually the Fiend is a Dock per workspace. How easy do you want it to be.
In GNUstep terms a workspace is the screen you are looking at including everything that is on it. That means the windows, the dock and the icons. You can have several workspaces to work on. Compare it to several virtual desks. If one desk is full, but you still need some work done, without pilling up everything that's there, you can switch to another that is still empty. The fact remains however that you once have to clean up the mess, a virtual desktop doesn't change that, sorry.
With the fiend you can manage those workspaces. You can switch from one to the other, name them and even assign tools that should be available on the different workspaces.
Easier? Okay. At the bottom of your screen you see two types of what look like icons, except just one is an icon, the other is a window. The left most, called App Icons, are the icons of running programs on the entire system (all workspaces), the mini-windows however are the programs running on the active workspace. If you still feel your desktop gets cluttered with windows while working (or if you want a clean screenshot for in a manual, without all kinds of open windows) you can minimize a window and it will stick to the bottom of your screen.
That's how easy it can get.
[ preferences setting time etc. TO BE WRITTEN ]
Project Center
In the Apps directory the applications for your system are stored. You'll see on the Icon path the icon of the application, while in the Viewer section you see that the application holds several other objects. An application in the Apps directory is actually a directory itself. All resources belonging to an application are stored within that directory. This makes system maintenance a bit easier. Removing an application just means deleting the corresponding .app 'file' in the Apps direcory.
The section about Project Center and GORM, the GNUstep development tools, will describe this .app 'file' in most detail, but to soothe your curiosity a bit a little explanation:
Within the directory you'll find the actual application build for your operating system. This is the actual executable. Next to that you'll find the path to the executable that is system dependant. Here Project Center was build on a ix86 machine. This way you could build Apps for different architectures, build one binary package and send that into the world.
And also you might find here different direcories holding different resources, like additional libraries, images, sound, etc.
In the previous chapter we have seen that an application is actually a directory with an executable and all its resources. Such a directory is called a bundle.
To most developers the terms bundle and framework will be new. But for a good understanding of GNUstep they are essential, so we will explain them in some more detail here.
A bundle is, as said before, a collection of resources making up a discrete package for use. There are currently three types of bundles: applications, frameworks and loadable bundles. The first one, the application, should be clear by now, so let's start with frameworks.
A framework is a dynamic shared library with all its resources; including header files, documentation. It could even contain several different versions of a library for e.g. backwards compatibility.
A loadable bundle is a kind of like a plug-in, except that there are two types of loadable bundles, namely plug-ins and palettes. A plug-in is a bundle that can be loaded by an application to provide additional functionality, while a palette is a plug-in for GORM, the interface builder. A palette is used to extend GORM with custom UI objects. Palettes have a .palette extension.
This, create everything independent from everything else, is the general approach of GNUstep. The less dependancies, the less changes things go wrong. The same approach is choosen in the entire setup of the system. By building abstraction layers within the system, hardware, operating system and user interface are separated. Not only for the user, but also for the developer. As you will see, this makes life easier, with less changes of conflicts.
The idea of implementing OpenStep for GNU, is very NeXT oriented. Like NeXT GNUstep is best implemented as a system on the OS, with a clear distinction between the two. Default the GNUstep tree is placed in a separate directory, with everything belonging to GNUstep underneath it. The choice of this setup creates very little dependencies between the underlying OS and GNUstep.
OpenStep mainly consisted of two libraries: the Application Kit and the Foundation Kit. The Application Kit is responsible for all the graphics, and the Foundation Kit is responsible for all low-level work (not GUI related).
Here is a graphical view of the system that will be discussed in the next chapters:
| |||||||||
Table 1: The blue and light-green parts are the actual GNUstep parts.
In the following paragraphs we will describe the here presented system from bottom to top, but first we are going to start off with the Objective C language. The language in which the entire GNUstep system is written.
The Objective C runtime is part of the GNU C compiler (gcc). And also part of the NeXT and Mac OS X compilers. This paragraph will not further this discuss the runtime, we will concentrate on the the Objective C language
Objective C is not really a GNUstep part. It is not even an 'official' language. That is, there is no official standard that describes Objective C. Brad J. Cox developed the original Objective C language, by adding SmallTalk-80 extensions to C. Dennis Gladding wrote the first GNU version in 1992, shortly followed by the second version by Richard Stallman. In 1993 the next version appeared written by Kresten Thorup who also used this version for the actual NeXT implementation. Later versions where maintained by Ovidiu Predescu and currently (2001) Stan Shebs of Apple Computer Inc. is the responsible person.
The GNUstep libraries are written using Objective-C. Objective-C is ANSI standard C with a relatively small set of smalltalk-like object oriented syntax grafted on to it. It is considered to be the most dynamic of the C based OO languages.
For complete Objective C tutorials you could read the online NeXT manual or use Apples Cocoa documentation. Or you could start with an easy initial tutorial at: http://www.tenon.com/products/codebuilder/Objective-C.shtml
Here is a feature by feature comparison between C++, Java, and Objective-C:
|
|
C++
|
Java
|
Objective-C
|
|---|---|---|---|
|
Binding Time
|
Either
|
Either
|
Either
|
|
Operator Overloading
|
Yes
|
No
|
No
|
|
Garbage Collecting
|
No
|
Yes
|
Possible
|
|
Inheritance
|
Yes
|
Yes
|
Yes
|
|
Activation/Passivation
|
No
|
Yes
|
Yes
|
|
Multiple inheritance
|
Yes
|
No
|
No
|
|
Supports Protocols/Interfaces
|
No
|
Yes
|
Yes
|
|
Supports Categories
|
No
|
No
|
Yes
|
Special Features of Objective-C
Objective-C has some special features which make the language elegant and easy to use. These are protocols and categories.
Protocols in Objective-C are very much like interfaces in Java. A protocol declares the methods which should be implemented on a class which defines a given protocol. Since Objective-C lacks multiple inheritance, we can use Protocols to make up for this. I personally don't like the idea of multiple inheritance, but to each his own. Speaking of multiple interhitence, it is possible to make up for the absence of protocols/interfaces in C++ by using an abstract base class combined with multiple inheritence. Although this is somewhat kludgy it will work, but there is no denying that the Objective-C and Java way of doing this is much cleaner.
Categories allow you to add or repair functionality of a given class without having access to its source code. Whenever an object of the type you added the category to is instantiated within your program, it has the extra methods you added to it.
Here starts the insight of the great benefits of a layered system. By abstracting GNUstep from the actual windowing system (On Unix X, Windows for Microsoft products and DPS for e.g NeXT and Apple operating systems) life gets better.
A windowing system is a piece of software that talks to the hardware (graphics adapter) that displays letters and images on your screen. This is the first step in making sure, next to the OS ofcourse, that applications and thus developers do not need to worry about what kind of hardware is installed. This is not a GNUstep achievement, but just fact of life.
To make this a bit more clear, Unix systems mostly use the X window system. The GNUstep developers were faced with the fact that OPENSTEP uses Display PostScript to draw everything on your screen. This are two totaly different systems. It would take too long to write a complete Display PostScript system from scratch so they tool another approach. They split the Application Kit into two parts. The GUI part that talks to the application and the backend part that talks to the windowing system.
Currently there are two different backends. One is xdps and the other is xgps.
xgps is the one that is used to talk to the X windowing system. xdps however is the one that is able to talk to a PostScript windowing system.
To get a Display PostScript system you could do three things. First you can buy one from Adobe, second you could use DGS (Display Ghostscript System) or you could use the dps extension for XFree86.
The DPS extion for XFree is available as of XFree86 4.0, so you need the 4.0 version of higher to make use of the DPS part. It is important to understand that DPS/X does not replace the X server, but extends it. So if you are using XFree86 version 4.0 or higher and you do not have the DPS server module, just download the source compile it and you are ready.
DGS is the OpenSource implementation of DPS, and uses Ghostscript for its PostScript handeling. DGS is not a server extension, but a standalone program that provides DPS services to the client by talking to the X server using core X, in Adobe parlance, a DPS/NX agent.
What should you choose? Currently xgps is the fastest backend available and it also is the default backend. However xdps offers you WYSIWYG (What-You-See-Is-What-You-Get).
The great thing is that the backends are implemented as bundles, meaning that you can switch on the fly, you as a developer don't need to worry about which backend to use. That is the benefit of a layered system, and how GNUstep shields you from system dependend matters.
As a developer you probably don't wanna know anything about every OS. You don't want to know the internals of Windows, Unix and Mac OS. You want a clean API for your programs to talk to. On the non-graphical side that will be the Foundation Kit for you. This Kit gives you all you need to write non-graphical applications.
The Foundation Kit or gnustep-base (as it is called in GNUstep) includes the root class, classes for basic data types, like strings and byte arrays, classes for storing objects and ofcourse classes representing system information, like date and time, communication ports, etc.
This is probably what you all have been waiting for, a complete system independent API to write your applications against and what makes them portable. A true write once, compile everywhere system. The Application Kit (the entire blue part in table 1) makes it happen.
But as you can see the Application Kit consists of two different pieces of work: gnustep-gui, and gnustep-back. Let's discuss them one by one.
gnustep-back is a back-end system with which you as a developer need not be concerned. It is this piece of software that talks to the windowing system and does all the neat stuff to make your program look as you intended it to be.
A more important piece for you is gnustep-gui. This is the API that your applications will talk to. gnustep-gui is what is described in the OpenStep standard as the Application Kit from a programmers point of view. The other two are just their to make it easy on the GNUstep developers part and to make portability as easy as possible. You see, just writing a new backend for a complete different windowing system is easier then writing a new Application Kit.
The GNUstep filesystem expects certain things to be in a certain place. Although applications can be placed everywhere on the system (they are self contained afterall), it might be that some things might not work directly if they are not placed in the Apps directory.
The Workspace manager e.g. searches on startup for available resources on the system so the resources (services) can be offered to other applications. Now imagine that an tiff-image viewer is not placed in the Apps directory, so the workspace manager doesn't know there is a tiff-viewer around. When you want to open a tiff in an editor you'll have to point the editor to the place where the tiff-viewer is.
This is not convinient. So you are advised to place the software where it belongs, and to explain where things belong, we have a little chapter about that.
First of all a little bit about the conventions used. A directory seperator in this chapter will be the / on Windows systems this is actually the \, so people using GNUstep on Windows should remember to read \ when they see /.
Another thing is the place where GNUstep is installed. The entire GNUstep system lives in it's own tree, but that could be placed everywhere. The default on Unix systems is /usr/GNUstep, but it could also be /opt/GNUstep or every other place for that matter. To make it easy we will call /GNUstep the root.
Okay, that's a start we have the root of GNUstep. Directly under the root directory you will find three direcories:
System
Network
Local
System and Local have the same structure. The only difference is that System contains the default (pre-installed) stuff, while Local contains those software products you installed yourself e.g. from source. And another thing that is also different is the /GNUstep/Local/Users directory. Since GNUstep is created for use on a multi-user system this directory is meant for the users home-directories. Default one user is present in this directory and that is Administrator.
The Network directory is empty by default. The idea is that you could share your applications across networks. That way you could save on diskspace and maintenance. The default way to share your information is by using the system-name as the mount point (mapping) and use the tree as described in the '/GNUstep/System tree'-section underneath that.
The first directory we introduce is the Makefiles-directory. GNUstep has it's own makefile system. GNUstep Make is a system of scripts that allows you to create a simple Makefile which in turn allows you to compile, install and even distribute in RPM or deb format the package you're building. A more complete description can be found in the gnustep-make section.
This directory holds everything that is needed for the Make-system.
Ofcourse there is the Apps directory, but you already knew that. But one major point is still to be made. The Apps directory only contains graphical applications. The none graphical applications are in the Tools directory. All commandline tools can be found here.
The Documentation directory speaks for itself I guess. It contains the documentation.
Now to someting more exciting the Developer directory. This directory holds all the developer resources. Including the Palettes for GORM. What's however not contained in this directory are the header files. Those files are so important that they deserved a directory of their own called Headers.
Are we left with two more directories that create sometimes some confusion due to their naming. One is called Library and the other Libraries. The most simple way is to think about a Library where you can get books. That is a place that holds information, where Libraries on the otherhand is just plural for library which is a piece of software that is a shared object.
The Library directory contains resources like bundles, colors, services, etc which can be read by the system. Like in a real Library.
The Libraries directory on the contrary contains the libraries sorted on architecture and operating system. Meaning that Libraries/ix86/linux-gnu/gnu-gnu-gnu contains the Foundation and Application Kit libraries for your GNUstep system. Or is it our GNUstep system?
The path ix86/linux-gnu/gnu-gnu-gnu has a special meaning. GNUstep is capable of providing binaries for more than one architecture to live in one directory. This way you as a developer can create so called 'fat' bundles. That are packages containing the binaries for all architectures you want to support, so you only have to maintain one archive. This is easy for you, but the system needs to know which binary to start. Executing a PPC executable on an Intel processor, is mostly not a good idea.
To solve this there is a tree within every bundle that has a path to the system dependant program or library. The first part is the hardware indicator. For Intel that is ix86. The second part describes the operating system. In our case we are running GNU/Linux (meaning the Linux kernel and the GNU tools), and the last part describes how GNUstep was build. The gnu-gnu-gnu tells us that from left to right, the Objective C runtime used was the GNU one (which is correct since it was the one from the GNU C compiler gcc), the second part tells us that the Foundation library was the GNUstep one. It is possible to build GNUstep with a NeXT system then it would have shown nx. And the last part is the Application Kit part, which also happens to be the GNUstep version.
To give you a better understanding of this here is a little table to explain a couple of the possible combinations:
|
The makefile package is a simplistic, powerful and extensible way to write makefiles for a GNUstep project. It allows the user to easily specify a library combination he/she wants to use when compiling a project. It also allows the user to easily create cross-compiled binaries.
Theoretically an OpenStep application should only use OpenStep API, it should not rely at all on system specific header files. This is the most portable way to write an OpenStep application. For this kind of applications configuring is not necessary since no system specific header files or libraries need to be checked. The idea is to try eliminate the configuring process because of the problems it has in the presence of cross-compiling. Not relying on system files in a GNUstep project means that you don't need to check for them, so the project can simply be compiled by just typing `make'.
This is in an ideal world, but we all know we aren't living in one, so sometimes some configuring is needed, and thus the makefile package supports it.
A project consists of a collection of source code files and resource files. If a project has several subdirectories, those subdirectories are subprojects of the main project. A subproject type is not restricted in any way by the type of the project it's contained into. The only restriction is that you can not create multiple project types from the files in the same directory.
For a project that does not need any additional configuring before compiling the only thing required to build the project should be typing:
$ make
The different types of projects that can be build can be found in the GNUstep/System/Makefiles directory. The different pre-defined makefiles all have the .make extension.
After the build is complete the binaries end up in a separate directory, which contains the binaries sorted by target system and development environment. This way you can build multiple targets from one source tree and create a so called fat binary, which is a package containing binaries for different targets.
Projects that require running configure before compiling
There are two issues with this kind of projects. 'configure' is used to determine the existence of particular header files and/or of some specific functionality in the system header files. This thing is usually done by creating a config.h file which contains a couple of defines like HAVE_... which say if the checked functionality is present or not.
Another usage of configure is to determine some specific libraries to link against to and/or some specific tools. A typical GNUstep program is not required to check for additional libraries because this step is done by the time the makefile package is installed. If the project still needs to check for additional libraries and/or tools, the recommended way is to output a config.mak file which is included by the main makefile, instead of using Makefile.in files which are modified by configure. The reason for not doing this is to avoid having the Makefiles contain target dependencies like above, this way keeping only one makefile instead of several for each target machine.
The makefile package is written for GNU make because it provides some very powerful features that save time both in writing the package but also at runtime, when you compile a project.
How to build a package for different architectures
In order to build a project for multiple architectures you'll need the development environment for the target machine installed on your machine. This includes a cross-compiler together with all the additional tools like the assembler and linker, the target header files and all the libraries you need.
The GNUstep makefile package is able to compile and link an application for another machine just by typing
$ make target="target machine"
where "target machine" is the canonical system name as reported by config.guess.
Building different types of a project
During development you usually need to switch between a debug version and a profile one without having to recompile all of the sources. The makefile package allows you to do this by letting you define three boolean make variables. The values of these variables can be either "yes" or "no".
If the value is yes then it is assumed that the target is to be built with debugging info. By default the optimization is turned on but you can control this behavior via the OPTFLAGS make variable. The default is no.
It makes sense to specify this only for library targets. This variable says if the target needs to be built as a shared library. On systems that support shared libraries this is the default; the user has to explicitly specify shared=no on the command line.
For example if you want to build a shared library with debug information enabled but no profile information, the command line would be:
$ make shared=yes debug=yes profile=no
The last argument is not necessary because the default is to build a version without profile information.
The object files will be output into the shared_debug_obj directory. If the profile is turned on the output directory would be shared_profile_debug_obj.
Naming conventions of the libraries
Sometimes you need to have different versions of a library compiled with different options. Suppose you want to compile a library with profiling information enabled so that you can profile your code. But you don't want to overwrite your existing installed library so that only some of the applications will work with the profile library, the rest will still use the normal library.
The makefile package supports such a schema by having different names for different types of the same library. This works by appending an underscore after the name of the library followed by a letter which indicates the type of the library:
's' for a static library
'p' for a profile library
'd' for a debug library
So for example if you have the library 'example' compiled with debug information as a shared library it would be named libexample_d.so.
It is possible to compile a library with whatever combination of flags you want. The letters are appended in the order specified above, so if you compile the library as a static library, with profile and debug information enabled, the library name will have the _spd suffix appended.
How a library is chosen
What happens if you compile an application with profile enabled and you don't have a library compiled with profile info into it, but you do have a normal library installed? It would be great if the normal library is chosen instead. This is a problem because the library that should be chosen has a different name than the profile library.
This schema is supported by requiring the libraries to be specified using the short name, without any suffix appended to it. The `example' library in our case should be passed to the linker using -lexample, and not using -lexample_p. Based upon the shared, profile and debug variables, the makefile package will identify which are the libraries that exist on the system and it will come with the correct names when linking.
The search order of libraries depending on what type of library is required is as follows. First of all an exact match is searched; if one is found it is returned. If either debug or profile are required, a library that matches at least one of these attributes is returned. For example if there is a profile+debug version of a library but only debug is required this library will match. If a static version is required but no static versions of the library exist, then no library is chosen; in this case the system simply prints out the name of the library, assuming a static library is somewhere else in the libraries search path of the linker.
Building applications
In the makefile's package terminology an application is a program linked against the GUI libraries.
An application is built as usualy, by compiling all of the sources and then linking the object files into the binary. The only difference between an application and any other project is that the application is created into its own directory, instead of being a simple file. This directory is called the application wrapper and it contains the binaries for various architectures and resources needed by the application.
The name of the application wrapper is taken to be the name of the application
with the following extensions:
.profile - if the application has been built with profile enabled
.debug - if the application has been built with debug enabled
.app - if the application has been built without debug or profile enabled
If both debug and profile are enabled, the application extension will simply have the .profile extension. This is different from libraries were both options are reflected into the library's name.
The structure of makefiles
The makefile package is built so that a user project will only have to define which Objective-C files he/she uses, which C files, which header files and so on. All the rules that know how to build a library, an application or whatever type of project are defined in the internal files of the makefile package.
This organization has several advantages. The main advantage is that the makefiles in a GNUstep project are small, only the makefile variable definitions. The other advantage is that all the build knowledge is centralized in a single place, the makefile package. Meaning that the most of the makefile code is shared, no-one needs to re-invent the wheel.
The way the main makefile of a project should be written requires the user to specify the files needed by the make process and what kind of project needs to be built. This is defined by including a certain makefile package file. For example if the package to be built is an application then a possible Makefile can look like this:
APP_NAME = test1 test2test1_OBJC_FILES = test1.m
test2_OBJC_FILES = test2.m test21.m
-include Makefile.preamble
include application.make
-include Makefile.postamble
The main makefile will be generated automatically by ProjectCenter. This however presents problems if the user wants to add his/her own makefile targets or additional rules. Two additional files are provided: Makefile.preamble and Makefile.postamble. The first file is included before the makefile for the specific project type and is intended for redefining the standard variables or for adding to them. The second one is intended for adding additional rules or targets.
Further reading
See Nicola Pero's tutorial on writing GNUstep Makefiles or the Makefile tutorial at www.gnustep.org
The gnustep-base package provides the Foundation classes. This means that with gnustep-base you can build non-graphical applications, which are called Tools.
This package provides an abstraction layer for gnustep-gui. You need this if you want to write graphical applications. It substracts the grahical interface dependant stuff from the gui-library. gnustep-back is the one that is talking to the actual graphics engine, like X-windows, or the MS Windows system. It takes care of handling fonts, images and the like.
This is the part you want when developing graphical applications. This is the GNUstep GUI library.
The two main applications which are used for rapid application development under GNUstep are ProjectCenter and GORM. These applications are still in beta, so this is just to give you a glimpse of what the near future holds.
ProjectCenter is the GNUstep equivalent of ProjectBuilder. Here is a screenchot of the application:
Future versions of PC.app will include a fully integrated debugger and an emacs-like editor. Currently PC.app can be used to some degree to edit files and to build projects, but it is currently in beta.
Further reading
A manual about how to use PC and GORM can be found at http://www.gnustep.it/pierre-yves/index.html
A description can be found at http://www.gnustep.org/experience/DeveloperTools.html
GORM stands for GNU Object Relationship Modeller. Here is a snapshot of GORM:
GORM allows developers to quickly create GUIs for an applications. For example, in order to assign an action, control-click on the control you wish to assign a method to and drag the double-sided arrow to the object you wish to call that method on. A dialog will appear with the names of all of the methods you can choose from. For instance, if I wanted method foo to be called on an instance of Controller when I press a button on the GUI all I need to to is control-click on the button which will then be marked with an "S" for source and then drag the double-sided arrow to the Controller object, which will then be marked with a "T" target. When the dialog appears, you can then choose the foo method from the list. The reverse applies when you wish to display the value of a variable on the GUI. First control-click on the object whose attribute you wish to display, then drag to the text field on which it should be shown.
Further reading A manual about how to use PC and GORM can be found at http://www.gnustep.it/pierre-yves/index.html
A description can be found at http://www.gnustep.org/experience/DeveloperTools.html