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

Update docs, prerelease version 0.9.0

Browse source 
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/tools/make/trunk@8546 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
Adam Fedor 2001-01-10 18:04:50 +00:00
parent 3c479f0fed
commit a7d7d2d4aa
14 changed files with 2176 additions and 31 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
.cvsignore
View file

@ -12,3 +12,4 @@ openapp
debugapp
executable.template
opentool
gnustep-make.spec

7
ChangeLog
View file

@ -1,3 +1,10 @@
2001-01-10 Adam Fedor <fedor@gnu.org>
* Version: Prerelease version 0.9.0
* Documentation/GNUmakfile.in: New targets to make documentation.
* Documentation/make.texi: New file
2001-01-08 Adam Fedor <fedor@gnu.org>
* GNUmakefile.in (MAKE_FILES): Add rpm.make and template.spec.in

17
Documentation/.cvsignore
View file

@ -1,2 +1,17 @@
GNUmakefile
version.texi
*.log
*.dvi
*.ps
*.html
*.info
*.aux
*.toc
*.cp
*.fn
*.vr
*.tp
*.ky
*.pg
*.ps
*.vrs

493
Documentation/DESIGN Normal file
View file

@ -0,0 +1,493 @@
A makefile package for the GNUstep environment
================================================================
This document presents a makefile package for the GNUstep
environment. It describes what are the goals the GNUstep environment
should achieve and then presents some solutions.
Goals
=====
There are several issues we tried to solve while designing a directory
structure and the configuration/make procedures required to build a
package.
We tried to define a directory structure for keeping all the GNUstep
related files. This structure makes the things more consistent and the
configuration and compile process of various GNUstep packages more
easier.
An important issue is to let to a package the ability to deal with
various libraries and configurations available now:
* different Objective-C runtimes. In the Objective-C world there are
currently two major runtimes: the NeXT runtime and the GNU
runtime. They are different in several respects and a program or
library that works at the runtime level should be aware of them.
* different Foundation libraries. There are several Foundation libraries
an OpenStep application can be written on top of: NeXT Foundation
library which runs on NeXTStep/OPENSTEP systems, PDO (Portable
Distributed Objects) which runs on a variety of Unix systems,
gnustep-base and libFoundation.
* different graphical interfaces. Until now two libraries provide or
try to provide OpenStep compliant systems: the AppKit from NeXT and
the GNUstep graphical libraries.
The makefile package should be a simplistic, powerful and extensible
way to write makefiles for a GNUstep project. It should allow the user
to easily specify a library combination he/she wants to use when
compiling a project. Also it should allow the user to easily create
cross-compiled binaries.
Library combinations
====================
If an application 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 an application compiled for NeXT PDO that
runs with gnustep-base or vice-versa. To summarize, an application can
be compiled for these combinations:
Objective-C runtime: NeXT, GNU
Foundation library: NeXT, PDO, gnustep-base, libFoundation
GUI library: NeXT, gnustep-gui
Back-end library: nil, XDPS, Win32
The back-end library is required if the GUI library used is
gnustep-gui. It is "nil" if the GUI library is NeXT's AppKit. We'll
use the following abbreviations to identify different parts:
Objective-C runtime: nx (for NeXT), gnu (for GNU)
Foundation library: nx (for NeXT), pdo (for PDO), gnu (for gnustep-base),
fd (for libFoundation)
GUI library: nx (for NeXT), gnu (for gnustep-gui)
Back-end library: nil (for none), xdps (for XDPS), w32 (for Win32)
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-nil. An application compiled for
PDO with the gnustep-gui library under Unix will be denoted by
nx-pdo-gnu-xdps and another one compiled for gnustep-base using
gnustep-gui under Unix will be denoted by gnu-gnu-gnu-xdps. Here is a
list of some of the possible combinations:
ObjC runtime Foundation GUI Backend
------------ ---------- --- --------
nx nx nx nil
nx pdo nx nil
nx pdo gnu xdps
gnu gnu gnu xdps
gnu gnu gnu w32
nx fd gnu xdps
gnu fd gnu xdps
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.
Directory structure
===================
There are several directories used in a GNUstep environment. The
directories are relative to a top directory whose name is given by the
variable GNUSTEP_SYSTEM_ROOT ($GNUSTEP_SYSTEM_ROOT in a shell or
$(GNUSTEP_SYSTEM_ROOT) in a makefile). Below is the hierarchy of
GNUstep directories:
$(GNUSTEP_SYSTEM_ROOT)/
Headers/
Libraries/
Apps/
Tools/
The Headers/ and Libraries/ directories, as their names suggest, keep
the header files and the libraries required by a GNUstep project to
compile and link. The libraries can be both shared or static,
depending on the target system.
The Apps/ directory is used by GNUstep graphical applications, those
applications which have a graphical interface with the user. The
Tools/ directory holds command line tools based on GNUstep libraries.
The header files are grouped like this in the Headers/ directory:
Headers/
gnustep/
base/
Foundation -> base
gui/
AppKit -> gui
libFoundation/
Foundation/
The Libraries/ directory can hold libraries for several machines and
several combinations of packages:
Libraries/
i386/
linux-gnu/
gnu-gnu-gnu-xdps/
libgnustep-base.so
libgnustep-gui.so
libgnustep-xdps.so
gnu-fd-gnu-xdps/
libFoundation.so
libgnustep-gui.so
libgnustep-xdps.so
sparc/
solaris-2.5.1/
nx-pdo-gnu-xdps/
libgnustep-gui.so
libgnustep-xdps.so
Please note that the Libraries/ directory contains only the libraries
that come with GNUstep, the PDO library for example is not inside
Libraries/. The compiler has to know where that library can be found,
although the makefile package is responsible for passing all the
necessary flags during compiling and linking.
The libraries directory also contains resource files which belong to
the GNUstep libraries, such as images and printer description
files. Since the images can look different for different backends,
each backend has its own images in a different directory based upon
the interface look and feel:
Libraries/
Resources/
Images/
NeXT/
Win32/
PrinterTypes/
Fonts/
gnustep/
NSCharacterSets/
libFoundation/
CharacterSets/
Defaults/
TimeZoneInfo/
The resources that are specific to each Foundation libraries are kept
in a subdirectory like above, except for NeXT Foundation and PDO which
keep their resources in their own places.
The Apps/ directory contains GNUstep graphical applications. Each
application is kept in an app wrapper which contains all the binaries
and all the resource files the application needs. The binaries
organization resembles the one from libraries:
Apps/
InterfaceModeller.app/
InterfaceModeller (for OPENSTEP systems compatibility)
i386/
linux-gnu/
gnu-gnu-gnu-xdps/
InterfaceModeller
sparc/
solaris-2.5.1/
nx-pdo-gnu-xdps/
InterfaceModeller
The Tools/ directory contains command line tools. Each tool
executable is placed in a subdirectory corresponding to the CPU and
operating system.
Tools/
i386/
linux-gnu/
autoconf
gcc
dgs
sparc/
solaris-2.5.1/
autoconf
gcc
The makefile package
====================
The GNUstep environment needs a makefile package whose purpose is to
simplify writing a GNUstep project. This package should help
developers easily write makefiles for compiling their projects.
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 the best scenario for a GNUstep package. If configuring is
still needed the makefile package should support it without major
changes.
We identified until now the following types of projects:
- application: for projects whose result are graphical GNUstep applications
- tool: for command line programs which use GNUstep libraries
- library: for creating libraries (both static and shared)
- bundle: for creating a dynamically loaded bundle
- aggregate: for projects that contain several other subprojects like
libraries, bundles and so on
Another possible type of project could be "pallete", for adding
functionality to the GNUstep InterfaceModeller application. Other
project types can be added as well, the makefile package does not
limit this in any way.
A project consists from 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
in the command line :-).
Where the object files go
=========================
The object files will go in a separate directory identified by the
name of the target system and of the development environment used
(ObjC runtime, Foundation library and GUI libraries). This way one can
use the same source tree for building the project for multiple
targets.
How to choose the library combination
=====================================
The makefile package will allow the user to choose between different
library combinations. To specify a combination you want to compile for
just type:
$ make library_combo="library combination"
For instance if you want to choose to compile using the NeXT's PDO
Foundation and use the GNUstep GUI library on a Unix machine you can
do like this:
$ make library_combo=nx-pdo-gnu-xdps
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 will be 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 should be 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".
* debug
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.
* shared
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 in the command line.
* profile
When this variable is yes, a profile version of the target is built. The
default is no.
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.
Of course you also have to specify the library combo if it's different than the
default.
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. If the same
library is compiled as a static library its name would be named
libexample_sd.a. The reason why the 's' letter for the static library appears
in name of the library is for systems where the extensions of libraries don't
matter.
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.
We do support this schema 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 results is that the first 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 should be built so that a user project will only
have to define what are the Objective-C files he/she uses, what are
the C files, the 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
we keep the makefiles in a GNUstep project small, only the makefile
variable definitions. The other advantage is that all the build
knowledge is centralized in a single place, the makefile
package. Right now each GNUstep package tries to solve all of the
issues related to the package building and nothing is reusable.
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 test2
test1_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 in the future by the
ProjectCenter. This presents problems if the user wants to add his/her
own makefiles 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.
The makefile package is installed under $(GNUSTEP_SYSTEM_ROOT)/Makefiles.
Ovidiu Predescu
Last updated: October, 1997

41
Documentation/GNUmakefile.in
View file

@ -25,11 +25,21 @@ GNUSTEP_PREFIX = @GNUSTEP_PREFIX@
srcdir = @srcdir@
datadir = @datadir@
GNUSTEP_MAKEINFO = makeinfo
GNUSTEP_MAKEINFO_FLAGS = -D NO-TEXI2HTML --no-header
GNUSTEP_MAKETEXT = makeinfo
GNUSTEP_MAKETEXT_FLAGS = -D NO-TEXI2HTML -D TEXT-ONLY --no-header --no-split
GNUSTEP_TEXI2DVI = texi2dvi
GNUSTEP_TEXI2DVI_FLAGS =
GNUSTEP_TEXI2HTML = texi2html
GNUSTEP_TEXI2HTML_FLAGS = -split_chapter -expandinfo
GNUSTEP_DVIPS = dvips
GNUSTEP_DVIPS_FLAGS =
include ../Version
# The documents to be generated
DOCUMENT_NAME =
DOCUMENT_NAME = make
# The text documents to be generated
DOCUMENT_TEXT_NAME = \
@ -53,7 +63,13 @@ ANNOUNCE_TEXI_FILES =
ANNOUNCE_TEXT_MAIN = announce.texi
ANNOUNCE_DOC_INSTALL_DIR = Developer/Makefiles/ReleaseNotes/$(VERSION)
make_TEXI_FILES = \
make.texi
all: $(DOCUMENT_TEXT_NAME)
for file in $(DOCUMENT_NAME); do \
$(MAKE) INTERNAL_doc_NAME=$$file TEXI_FILES=$$file.texi internal-doc-all; \
done
INSTALL: install.texi
$(GNUSTEP_MAKETEXT) $(GNUSTEP_MAKETEXT_FLAGS) \
@ -63,6 +79,29 @@ README: readme.texi
$(GNUSTEP_MAKETEXT) $(GNUSTEP_MAKETEXT_FLAGS) \
-o $@ $^
internal-doc-all:: $(INTERNAL_doc_NAME).info \
$(INTERNAL_doc_NAME).ps \
$(INTERNAL_doc_NAME)_toc.html
$(INTERNAL_doc_NAME).info: $(TEXI_FILES)
$(GNUSTEP_MAKEINFO) $(GNUSTEP_MAKEINFO_FLAGS) \
-o $@ $(INTERNAL_doc_NAME).texi
$(INTERNAL_doc_NAME).dvi: $(TEXI_FILES)
$(GNUSTEP_TEXI2DVI) $(GNUSTEP_TEXI2DVI_FLAGS) $(INTERNAL_doc_NAME).texi
$(INTERNAL_doc_NAME).ps: $(INTERNAL_doc_NAME).dvi
$(GNUSTEP_DVIPS) $(GNUSTEP_DVIPS_FLAGS) \
$(INTERNAL_doc_NAME).dvi -o $@
$(INTERNAL_doc_NAME)_toc.html: $(TEXI_FILES)
$(GNUSTEP_TEXI2HTML) $(GNUSTEP_TEXI2HTML_FLAGS) \
$(INTERNAL_doc_NAME).texi
regenerate: $(DOCUMENT_TEXT_NAME)
mv -f $(TOP_DOC_FILES) ..
version.texi: ../Version
rm -f version.texi
echo '@set GNUSTEP-MAKE-VERSION' $(GNUSTEP_MAKE_VERSION) \
> version.texi

14
Documentation/install.texi
View file

@ -117,17 +117,23 @@ GNUstep's NSInvocations and Distributed Objects code involves detailed
manipulation of function (method) calls, which does not work on all
machine architectures. A more robust and portable solution is to use a
library that implements a Foreign-Function Interface (FFI), such as the
ffcall libraries. If you use a non-x86 machine, you should seriously
consider enabling this option using @code{--enable-ffcall}.
ffcall libraries.
Use of the ffcall libraries are now @emph{highly recommended} for in the
GNUstep system. The old gcc __builtin_apply method used previously is
no longer supported and may at some time in the future be removed entirely.
Failure to use the ffcall libraries will make GNUstep's Distributed Objects
system incompatible with other GNUstep systems. The ffcall library is
required on most non-x86 machines for proper operation of invocations and DO.
For this to work, you need to have the ffcall libraries, which you can
get from @url{ftp://ftp.santafe.edu/pub/gnu/} or
@url{http://clisp.cons.org/~haible/}. You also need to have a special
version of the Objective-C library (as of gcc 2.95.x the required hooks
are not in the standard library). You can get this library from
@url{ftp://www.gnustep.org/pub/gnustep/contrib/libobjc-hh.tar.gz} or
@url{ftp://www.gnustep.org/pub/gnustep/libs/libobjc-20010105.tar.gz} or
patch the standard library with the patch at
@url{ftp://www.gnustep.org/pub/gnustep/contrib/libobjc-ffi.patch}.
@url{ftp://www.gnustep.org/pub/gnustep/libs/patches/libobjc-ffi.patch}.
Note that the ffcall libraries are GPL, not LGPL, but the copyright
holder has created a special exception when ffcall is linked with GNUstep:

1461
Documentation/make.texi Normal file
View file

File diff suppressed because it is too large Load diff

43
Documentation/news.texi Normal file
View file

@ -0,0 +1,43 @@
@c -*-texinfo-*-
@ifclear ANNOUNCE-ONLY
@chapter NEWS
@end ifclear
@ifset TEXT-ONLY
@include version.texi
@end ifset
The currently released version is @samp{@value{GNUSTEP-MAKE-VERSION}}.
@section Changes in version @samp{0.9.0}
ffcall library is highly recommended for use with the GNUstep base
library. You need to have installed it prior to configuring the Makefile
package. See the INSTALL file.
@itemize @bullet
@item Support for automatically generating RPM spec files.
@item Build suitable files for MacOS bundles
@item Add option for flattened directory structure.
@item LaText documentation support.
@item Added support for Frameworks
@end itemize
@ifclear ANNOUNCE-ONLY
@section Noteworthy changes in version @samp{0.6.6}
The GNUstep system libraries are now installed in a separate system root
directory (default /usr/GNUstep/System) rather than the GNUstep
root directory (default /usr/GNUstep). You can revert to the old behavior
using a configure option @samp{--without-system-root}. We also recommend
removing any previous GNUstep versions before installing the new one in order
to avoid problems with the system finding the correct binary and/or library.
@itemize @bullet
@item Support for Windows compilation (cygwin and mingw) and DLL creation
and usage.
@item Java support rewritten and extended.
@end itemize
@end ifclear
@c end ifclear ANNOUNCE-ONLY

5
Documentation/readme.texi
View file

@ -18,8 +18,9 @@ The file @samp{NEWS} has the library's feature history.
The files @samp{INSTALL} or @samp{GNUstep-HOWTO} (from the core package)
gives instructions for installing the library.
The file @samp{DESIGN} has information on the design of the Makefile
system and how to write your own makefiles that work with it.
Files in the @samp{Documentation} directory have information on the
design of the Makefile system and how to write your own makefiles that
work with it.
@section History

59
INSTALL
View file

@ -24,9 +24,9 @@ Additional Libraries
Configuration
=============
The GNUstep makefile package uses the Autoconf mechanism for
configuration; it checks some host capabilties which are used by all
GNUstep software. To configure just type:
The GNUstep packages uses the Autoconf mechanism for configuration;
it checks some host capabilties which are used by all GNUstep software.
To configure just type:
./configure
@ -42,6 +42,34 @@ following command makes /usr/local/GNUstep the root directory:
and you do not specify a root directory when running configure, then
configure will use /usr/GNUstep as the default root directory.
To see more options you can use with configure, type
./configure --help
Look particularly at the end of the list that configure gives, as
these options are specific to GNUstep. For instance, if you installed
the tiff library in other than a normal directory, you can use the
`--with-tiff-include' option to tell configure where it is.
With the various GNUstep libraries you can use the various switches,
shared and debug. As in "make shared=no debug=yes" (Make sure you use
the same switches for every package you compile, and also when you
install).
Alternate Library Setup
-----------------------
You can specify compilation of alternate libraries by using the
-with-library-combo option. You need to have these libraries unpacked
in a subdirectory under the gstep directory, then you can say
./configure --with-library-combo=gnu-gnu-gnu-xdps
to compile with the xdps library rather than the default xgps
backend. IMPORTANT: The xdps backend is still experimental. Do not use
it unless you are willing to deal with PostScript problems and other
bugs.
Reading Command-Line Arguments
------------------------------
@ -83,17 +111,32 @@ FFI Library
detailed manipulation of function (method) calls, which does not work
on all machine architectures. A more robust and portable solution is to
use a library that implements a Foreign-Function Interface (FFI), such
as the ffcall libraries. If you use a non-x86 machine, you should
seriously consider enabling this option using `--enable-ffcall'.
as the ffcall libraries.
Use of the ffcall libraries are now _highly recommended_ for in the
GNUstep system. The old gcc __builtin_apply method used previously is
no longer supported and may at some time in the future be removed
entirely. Failure to use the ffcall libraries will make GNUstep's
Distributed Objects system incompatible with other GNUstep systems. The
ffcall library is required on most non-x86 machines for proper
operation of invocations and DO.
For this to work, you need to have the ffcall libraries, which you
can get from <ftp://ftp.santafe.edu/pub/gnu/> or
<http://clisp.cons.org/~haible/>. You also need to have a special
version of the Objective-C library (as of gcc 2.95.x the required hooks
are not in the standard library). You can get this library from
<ftp://www.gnustep.org/pub/gnustep/contrib/libobjc-hh.tar.gz> or patch
the standard library with the patch at
<ftp://www.gnustep.org/pub/gnustep/contrib/libobjc-ffi.patch>.
<ftp://www.gnustep.org/pub/gnustep/libs/libobjc-20010105.tar.gz> or
patch the standard library with the patch at
<ftp://www.gnustep.org/pub/gnustep/libs/patches/libobjc-ffi.patch>.
Note that the ffcall libraries are GPL, not LGPL, but the copyright
holder has created a special exception when ffcall is linked with
GNUstep:
ffcall is under GNU GPL. As a special exception, if used in GNUstep
or in derivate works of GNUstep, the included parts of ffcall are
under GNU LGPL.
Make sure you specify this option when configuring gstep-base also.

38
NEWS Normal file
View file

@ -0,0 +1,38 @@
NEWS
****
The currently released version is `0.6.7'.
Changes in version `0.9.0'
==========================
ffcall library is highly recommended for use with the GNUstep base
library. You need to have installed it prior to configuring the Makefile
package. See the INSTALL file.
* Support for automatically generating RPM spec files.
* Build suitable files for MacOS bundles
* Add option for flattened directory structure.
* LaText documentation support.
* Added support for Frameworks
Noteworthy changes in version `0.6.6'
=====================================
The GNUstep system libraries are now installed in a separate system
root directory (default /usr/GNUstep/System) rather than the GNUstep
root directory (default /usr/GNUstep). You can revert to the old
behavior using a configure option `--without-system-root'. We also
recommend removing any previous GNUstep versions before installing the
new one in order to avoid problems with the system finding the correct
binary and/or library.
* Support for Windows compilation (cygwin and mingw) and DLL creation
and usage.
* Java support rewritten and extended.

5
README
View file

@ -21,8 +21,9 @@ Information
The files `INSTALL' or `GNUstep-HOWTO' (from the core package) gives
instructions for installing the library.
The file `DESIGN' has information on the design of the Makefile
system and how to write your own makefiles that work with it.
Files in the `Documentation' directory have information on the
design of the Makefile system and how to write your own makefiles that
work with it.
History
=======

4
Version
View file

@ -3,7 +3,7 @@
# The version number of this release.
MAKE_MAJOR_VERSION=0
MAKE_MINOR_VERSION=6
MAKE_SUBMINOR_VERSION=7
MAKE_MINOR_VERSION=9
MAKE_SUBMINOR_VERSION=0
GNUSTEP_MAKE_VERSION=${MAKE_MAJOR_VERSION}.${MAKE_MINOR_VERSION}.${MAKE_SUBMINOR_VERSION}

19
rpm.make
View file

@ -71,7 +71,9 @@ ifeq ($(RPM_MAKE_LOADED),)
RPM_MAKE_LOADED=yes
# Default variable settings
DATE=`date +"%Y%m%d"`
ifeq ($(DATE),)
DATE=`date +"%Y%m%d"`
endif
ifeq ($(RPM_RELEASE),)
RPM_RELEASE = 1
endif
@ -82,7 +84,7 @@ ifeq ($(PACKAGE_COPYRIGHT),)
PACKAGE_COPYRIGHT = GPL
endif
ifeq ($(RPM_GROUP),)
RPM_GROUP = Unknown/Unknown
RPM_GROUP = Development/Tools
endif
ifeq ($(PACKAGE_SUMMARY),)
PACKAGE_SUMMARY = $(PACKAGE_NAME) package
@ -102,12 +104,6 @@ endif
ifeq ($(PACKAGE_URL),)
PACKAGE_URL = http://www.gnustep.org/
endif
ifeq ($(RPM_CONFLICTS),)
RPM_CONFLICTS =
endif
ifeq ($(RPM_REQUIRES),)
RPM_REQUIRES =
endif
#
# Internal targets
@ -345,11 +341,12 @@ filelist-in:
# Just playing around with these for now
#
snapshot-dist:
SNAPSHOT_DIR=`basename `pwd``; \
PWD=`pwd`; \
SNAPSHOT_DIR=`basename $(PWD)`; \
cd ..; \
mv $SNAPSHOT_DIR $(PACKAGE_NAME)-$(VERSION); \
mv $$SNAPSHOT_DIR $(PACKAGE_NAME)-$(VERSION); \
tar --gzip -cf $(PACKAGE_NAME)-$(VERSION).tar.gz $(PACKAGE_NAME)-$(VERSION); \
mv $(PACKAGE_NAME)-$(VERSION) $SNAPSHOT_DIR
mv $(PACKAGE_NAME)-$(VERSION) $$SNAPSHOT_DIR
#