gnustep/tools-make
0
0
Fork 0
mirror of https://github.com/gnustep/tools-make.git synced 2025-04-22 22:00:49 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Add missing files

Browse source 
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/tools/make/branches/stable@25853 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
Adam Fedor 2008-01-04 02:40:23 +00:00
parent 2ec8419e66
commit 009689dce2
4 changed files with 393 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
Documentation/debugapp.1 Normal file
View file

@ -0,0 +1,44 @@
.\" Process this file with
.\" groff -man -Tascii debugapp.1
.\"
.TH debugapp 1 "16/12/2007" GNUstep "GNUstep System Manual"
.SH NAME
debugapp \- A wrapper for openapp.
.SH SYNOPSIS
.BR debugapp " [" \-\-find ]
.RB [ \-\-gdb=... ]
.IR application " [" arguments... ]
.P
.SH DESCRIPTION
.B debugapp
is a tool that helps you start or find applications by name in debugging mode. It acts as a wrapper around
.B openapp
, and calls openapp with the
.B \-\-debug
option; we recommend using openapp directly.
.P
By default gdb is used as the debugger, but this can be changed with the
.B \-\-gdb=
option or through the
.B GDB
enviroment variable.
.P
The
.I arguments
are the arguments passed to the application.
.P
See the
.B openapp
(1) man-page for a complete description.
.SH SEE ALSO
openapp(1)
.P
.SH HISTORY
Work on
.B debugapp
started in October 1997 by Ovidiu Predescu <ovidiu@net-community.com>.
In October 2006 Nicola Pero <nicola.pero@meta-innovation.com> merged it
with openapp.
.SH AUTHORS
This man page was written by Dennis Leeuw <dleeuw@made-it.com>.

88
Documentation/gnustep-config.1 Normal file
View file

@ -0,0 +1,88 @@
.\" Process this file with
.\" groff -man -Tascii gnustep-config.1
.\"
.TH gnustep-config 1 "24/12/2007" GNUstep "GNUstep System Manual"
.SH NAME
gnustep-config \- prints information about the current gnustep installation.
.SH SYNOPSIS
.BR gnustep-config " ["
.BI \-\-variable= variable
.RB | \-\-objc-flags | \-\-objc-libs | \-\-base-libs | \-\-gui-libs " ]"
.SH DESCRIPTION
.B gnustep-config
can print information about the currently installed GNUstep system. It can output dependend on the options used the different flags used for compilation, but also the different internal variables used by the make system.
.SH OPTIONS
.TP
.BI \-\-variable= variable
prints the value of the specified variable. Possible variables are:
.RS
.RS
.PD 0
.HP
GNUSTEP_MAKEFILES
.HP
GNUSTEP_USER_DIR
.HP
GNUSTEP_USER_DEFAULTS_DIR
.HP
GNUSTEP_HOST
.HP
GNUSTEP_HOST_CPU
.HP
GNUSTEP_HOST_VENDOR
.HP
GNUSTEP_HOST_OS
.HP
GNUSTEP_IS_FLATTENED
.HP
GNUSTEP_xxx_APPS
.HP
GNUSTEP_xxx_TOOLS
.HP
GNUSTEP_xxx_LIBRARY
.HP
GNUSTEP_xxx_HEADERS
.HP
GNUSTEP_xxx_LIBRARIES
.HP
GNUSTEP_xxx_DOC
.HP
GNUSTEP_xxx_DOC_MAN
.HP
GNUSTEP_xxx_DOC_INFO
.RE
where 'xxx' could be any of 'SYSTEM', 'NETWORK', 'LOCAL' and 'USER'.
.RE
.PD 1
.TP
.B \-\-objc-flags
prints all the flags required to compile an ObjC file
.TP
.B \-\-objc-libs
prints all the flags required to link a pure ObjC program (no foundation/gui)
.TP
.B \-\-base-libs
prints all the flags required to link a command-line ObjC program (no gui)
.TP
.B \-\-gui-libs
prints all the flags required to link a GUI ObjC program
.SH BUGS
None known
.SH SEE ALSO
GNUstep(7)
.SH HISTORY
Work on
.B gnustep-config
started in 2007 by Nicola Pero <nicola.pero@meta-innovation.com>
.SH AUTHORS
This man page was written by Dennis Leeuw <dleeuw@made-it.com>.
.SH COPYRIGHT
Copyright (C) 2007 Free Software Foundation, Inc.
.PP
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.

225
Documentation/library-combo.7 Normal file
View file

@ -0,0 +1,225 @@
.\" Process this file with
.\" groff -man -Tascii library-combo.7
.\"
.TH library-combo 7 "20/12/2007" gnustep-make "GNUstep System Manual"
.SH DESCRIPTION
This manual page is about cross-compilation and fat binaries. Fat binaries are packages that you can supply which contain more the one binary of your program (e.g. your application). So you can support multiple platforms with a single package.
.PP
To support this your system has to be built in a non-flattened way. Meaning that during the installation of
.I gnustep-make
you should have selected
.B \-\-disable-flattened
and the types of library combinations you want to support, through the
.B \-\-with-library-combo
option. With library combinations we mean the Objective-C runtime, the Foundation library and the Application library. For more details about this see the LIBRARY-COMBO section.
.PP
If you installed your
.B GNUstep
system in a non-flattened way all system dependend binaries are installed in subdirectories with
.I cpu/os/library-combo
information. That means for instance that the
.I gnustep-base
library will be installed in
.I Library/Libraries/ix86/linux/gnu\-gnu\-gnu/
when you are on an Intel x86 system, running linux with the
.SM GNU
runtime for Objective-C and you installed
.BR GNUstep .
.PP
For each and every library-combo that you want to support you should create the environment through
.IR gnustep-make ,
because it installs a different
.I config.make
to support its own
.BR CC ", " OPTFLAGS ,
etc. flags.
.SS LIBRARY-COMBO
An important issue is to let to a package the ability to deal with various libraries and configurations available now:
.TP
.B Objective-C runtimes
In the Objective-C world there are three major runtimes: the NeXT runtime, the Apple runtime and the
.SM GNU
runtime (both with and without garbage collection enabled). They are different in several respects and a program or library that works at the runtime level should be aware of them.
.TP
.B Foundation libraries
There are several Foundation libraries an application or tool can be written on top of: NeXT Foundation library which runs on NeXTStep/OPENSTEP systems, gnustep-base, libFoundation and Apple Cocoa system.
.TP
.B Graphical interfaces
Until now three libraries provide or try to provide OpenStep compliant systems: the AppKit from NeXT, gnustep-gui and Cocoa from Apple.
.PP
If a program wants to work with all the possible combinations it will have to provide different binaries for each combination because it's not possible to have a tool compiled for NeXT Foundation that runs with gnustep-base or vice-versa. To summarize, a program can be compiled for these combinations:
.TP
.B Objective-C runtime
nx (for NeXT), gnu (for
.SM GNU
without garbage collection), gnugc (for
.SM GNU
with garbage collection), apple (for Apple)
.TP
.B Foundation library
nx (for NeXT), gnu (for gnustep-base), fd (for libFoundation), apple (for Apple Cocoa)
.TP
.B GUI library
nx (for NeXT), gnu (for gnustep-gui), apple (for Apple Cocoa)
.PP
We'll denote the fact that an application was compiled for a certain combination of the above values by using the abbreviations of the different subsystems and placing dashes between them. For example an application compiled for NeXT Foundation using NeXT AppKit will have the compile attribute nx\-nx\-nx. An application compiled for Apple Cocoa with the
.SM GNU
compiler for Objective-C gnu\-apple\-apple and another one compiled for
.I gnustep-base
using
.I gnustep-gui
under Unix will be denoted by gnu\-gnu\-gnu. Here is a list of some of the possible combinations:
.PP
.RS 0
Runtime Foundation GUI
.RS 0
nx nx nx
.RS 0
nx fd gnu
.RS 0
gnu gnu gnu
.RS 0
gnu fd gnu
.RS 0
gnugc gnu gnu
.RS 0
gnugc fd gnu
.RS 0
apple apple apple
.RS 0
apple gnu gnu
.RE 0
.PP
Note that one can choose his/her own packages to build; it is not required to have all the packages installed on the system. Not having all of them installed limits only the ability to build and distribute binaries for those missing combinations.
.SS DIRECTORY STRUCTURE
For cross-compilation in a non-flattened directory structure is recommended, so that you can store on the same directory structure binaries for different machines. The standard
.B GNUstep
filesystem layout is normally used when a non-flattened directory structure is being used; this is obtained with the
.BI \-\-with-layout= gnustep
option when configuring
.IR gnustep-make .
The entire
.B GNUstep
installation is then created inside
.I /usr/GNUstep
(or another directory if you use the
.B \-\-prefix=...
option when configuring
.IR gnustep-make ).
Directories that contain binaries (such as the
.I Libraries
directory) inside
.I /usr/GNUstep
are then set up to support fat binaries as follows:
.PP
.RS 0
Libraries/
.RS 0
ix86/
.RS 0
linux\-gnu/
.RS 0
gnu\-gnu\-gnu/
.RS 0
libgnustep\-base.so
.RS 0
libgnustep\-gui.so
.RS 0
gnu\-fd\-gnu/
.RS 0
libFoundation.so
.RS 0
libgnustep\-gui.so
.PP
To allow the right libraries to be found, you need to source
.I GNUstep.sh
before using
.BR GNUstep ,
and you need to start up your application by using
.BR openapp ,
which will locate the right binary for your library combo.
.SS BUILDING FOR A LIBRARY-COMBO
The makefile package will allow the user to choose between different library combinations. To specify a combination you want to compile for just type:
.PP
.RS 0
$ make library_combo=library-combo
.PP
For instance if you want to choose to compile using the GNUstep's Foundation implementation and use the GNUstep GUI library on a GNU/Linux machine you can do like this:
.PP
.RS 0
$ make library_combo=gnu\-gnu\-gnu
.PP
If your project requires running configure before compiling there are two issues you have to keep in mind. '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.
.PP
Another usage of configure is to determine some specific libraries to link against to and/or some specific tools. A typical
.B 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
.I config.mak
file which is included by the main
.IR GNUmakefile ,
instead of using
.I Makefile.in
files which are modified by
.IR 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.
.PP
The makefile package is written for
.SM 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.
.SS BUILDING FOR AN ARCHITECTURE
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.
.PP
The
.B GNUstep
makefile package should be able to compile and link an application for another machine just by typing
.PP
.RS 0
$ make target=target-triplet
.PP
where target-triplet is the canonical system name as reported by
.IR config.guess .
.SS USING A LIBRARY-COMBO
When you use library-combos, you must always source
.IR GNUstep.sh .
That allows you to switch library paths on the fly. If you want to switch to a different library-combo in your shell, and if you are using
.BR bash ,
it's common to first source
.I GNUstep-reset.sh
to reset all shell variables, then to source
.B GNUstep.sh
again. Let's assume we use gnu-gnu-gnu as our current
.B LIBRARY_COMBO
and we want to switch to gnugc\-gnu\-gnu, then we would use:
.PP
.RS 0
. /usr/GNUstep/System/Library/Makefiles/GNUstep-reset.sh
.RS 0
export LIBRARY_COMBO=gnugc\-gnu\-gnu
.RS 0
. /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
.SH SEE ALSO
debugapp(1), GNUstep(7), gnustep-config(1), openapp(1)
.SH HISTORY
Work on gnustep-make started in 1997 by Scott Christley <scottc@net-community.com>.
.PP
Version 2.0.0 of gnustep-make introduced many changes with previous releases, which was mainly the work of Nicola Pero <nicola.pero@meta-innovation.com>
.SH AUTHORS
This man-page was written by Dennis Leeuw <dleeuw@made-it.com> based on the DESIGN document from the gnustep-make source tree.
.SH CREDITS
The DESIGN document was written by Ovidiu Predescu.
.PP
This work could only be as is due to the notes and corrects from Nicola Pero <nicola.pero@meta-innovation.com>.
.SH COPYRIGHT
Copyright (C) 2007 Free Software Foundation, Inc.
.PP
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.

36
Documentation/opentool.1 Normal file
View file

@ -0,0 +1,36 @@
.\" Process this file with
.\" groff -man -Tascii opentool.1
.\"
.TH opentool 1 12/12/2007 gnustep-make "GNUstep System Manual"
.SH NAME
opentool \- Command line tool for starting tools
.SH SYNOPSIS
.BR opentool " [" \-\-library-combo=... ]
.B tool
.RI " [" arguments... ]
.SH DESCRIPTION
.B opentool
is obsolete. You should make sure that the
.I Tools
directories are in your
.BR PATH ,
and then
.B opentool
is not needed anymore.
.SH SEE ALSO
openapp(1), debugapp(1), GNUstep(7)
.SH HISTORY
Work on
.B opentool
started in 1997 and was written by Scott Predescu <ovidiu@net-community.com>, Ovidiu Predescu <ovidiu@net-community.com> and Nicola Pero <n.pero@mi.flashnet.it>
.
.SH AUTHORS
This man page was written by Dennis Leeuw <dleeuw@made-it.com> December 2007.
.SH COPYRIGHT
Copyright (C) 2007 Free Software Foundation, Inc.
.PP
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.