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

Update

Browse source 
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/tools/make/trunk@39575 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
rfm 2016-03-21 07:02:56 +00:00
parent 457219b59a
commit a964f87bde
2 changed files with 237 additions and 207 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
ANNOUNCE
View file

@ -1,7 +1,7 @@
1 Announcement
**************
The GNUstep Makefile Package version 2.6.7 is now available.
The GNUstep Makefile Package version 2.6.8 is now available.
1.1 What is the GNUstep makefile package?
=========================================
@ -12,24 +12,36 @@ project without having to deal with the complex issues associated with
configuration, building, installation, and packaging. It also allows
the user to easily create cross-compiled binaries.
1.2 Changes in version `2.6.7'
1.2 Changes in version '2.6.8'
==============================
Improved package building support
Configure option '-with-library-combo=ng-gnu-gnu' to use the 'Next
Generation' setup of the latest ObjectiveC-2 runtime and compiler
features rather than traditional runtime. Requires the new runtime and
a recent clang compiler.
Improved environment variable support
Command line option 'documentation=no' to suppress builds of
documentation.
Improved Java support
Integration of testsuite for regression/unit testing of libraries
using the 'check' target. In your makefile define libraryname_TEST_DIR
= TestsSubdirectory
Various minor bugfixes, documentation spelling corrections etc.
The '-enable-strict-v2-mode' option is now, after eight years, turned
on by default (in anticipation of finally removing backward
compatibility with version one). WARNING; Packagers please ensure that
you update any old gnustep-make version one makefiles.
Garbage collection support to be removed at the next release.
1.3 Obtaining gnustep-make
==========================
You can get the gstep-make-2.6.7.tar.gz distribution file at
`ftp://ftp.gnustep.org/pub/gnustep/core'
You can get the gstep-make-2.6.8.tar.gz distribution file at
<ftp://ftp.gnustep.org/pub/gnustep/core>
Please log bug reports on the GNUstep project page
`http://savannah.gnu.org/bugs/?group=gnustep' or send bug reports to
<http://savannah.gnu.org/bugs/?group=gnustep> or send bug reports to
<bug-gnustep@gnu.org>.

414
RELEASENOTES
View file

@ -5,7 +5,35 @@ The release notes include descriptions of API changes, behavior changes
and other information that might help developers and users migrate to
using a newer version of the make system.
1.1 Version 2.6.7
1.1 Version 2.6.8
=================
Configure option '-with-library-combo=ng-gnu-gnu' to use the 'Next
Generation' setup of the latest ObjectiveC-2 runtime and compiler
features rather than traditional runtime. Requires the new runtime and
a recent clang compiler.
With the 'ng' runtime in use, you can define GS_WITH_ARC=1 at the
start of a makefile, or in your environment, or in the command line
arguments to have objC code built using ARC.
Command line option 'documentation=no' to suppress builds of
documentation.
Integration of testsuite for regression/unit testing of libraries
using the 'check' target. In your makefile define libraryname_TEST_DIR
= TestsSubdirectory
Various minor bugfixes, documentation spelling corrections etc.
The '-enable-strict-v2-mode' option is now, after eight years, turned
on by default (in anticipation of finally removing backward
compatibility with version one). WARNING; Packagers please ensure that
you update any old gnustep-make version one makefiles.
Garbage collection support to be removed at the next release.
1.2 Version 2.6.7
=================
Improved package building support
@ -16,14 +44,14 @@ Improved package building support
Various minor bugfixes, documentation spelling corrections etc.
1.2 Version 2.6.6
1.3 Version 2.6.6
=================
Debian packagge generation support added.
Bug fixes
1.3 Version 2.6.5
1.4 Version 2.6.5
=================
Bugfix for non-fragile ABI test
@ -34,47 +62,46 @@ Bugfix for non-fragile ABI test
Added minimal test support for .c and .cc files.
1.4 Version 2.6.4
1.5 Version 2.6.4
=================
Test framework enhancement (extended equality tests)
Android build target
1.5 Version 2.6.3
1.6 Version 2.6.3
=================
Bug fixes
1.6 Version 2.6.2
1.7 Version 2.6.2
=================
`Added standalone filesystem layout for putting everything in'
'Added standalone filesystem layout for putting everything in'
one directory for easy deployment of relocatable
`Other bug fixes'
'Other bug fixes'
1.7 Version 2.6.1
1.8 Version 2.6.1
=================
Bug fixes
1.8 Version 2.6.0
1.9 Version 2.6.0
=================
`The default filesystem layout is now the 'fhs' layout'
'The default filesystem layout is now the 'fhs' layout'
Before version 2.6.0, the default filesystem layout was the
'gnustep' layout. Starting with 2.6.0, the default filesystem
layout has changed and is now the 'fhs' layout. To get the old
default layout, configure gnustep-make using ./configure
-with-layout=gnustep. Note that this change does not affect
gnustep-make when used with the apple-apple-apple library combo,
in which case the default filesystem layout remains the 'apple'
one.
gnustep-make when used with the apple-apple-apple library combo, in
which case the default filesystem layout remains the 'apple' one.
The change in the default filesystem layout means that the
location of the GNUstep.sh file in a default installation has
changed from /usr/GNUstep/System/Library/Makefiles/GNUstep.sh to
The change in the default filesystem layout means that the location
of the GNUstep.sh file in a default installation has changed from
/usr/GNUstep/System/Library/Makefiles/GNUstep.sh to
/usr/local/share/GNUstep/Makefiles/GNUstep.sh. If you use the
default layout and execute the GNUstep.sh script on startup, you
need to change the command from
@ -85,11 +112,11 @@ Bug fixes
. /usr/local/share/GNUstep/Makefiles/GNUstep.sh
`The default location of the configuration file changed'
'The default location of the configuration file changed'
Before version 2.6.0, the configuration file was always by default
/etc/GNUstep/GNUstep.conf no matter what filesystem layout and
prefix were used. Starting with version 2.6.0, that is the
default location of the configuration file only when installing
prefix were used. Starting with version 2.6.0, that is the default
location of the configuration file only when installing
system-wide, that is with a prefix set to /, /usr or /usr/GNUstep.
In all other cases, the configuration file is by default located in
$prefix/etc/GNUstep/GNUstep.conf.
@ -109,43 +136,42 @@ Bug fixes
file on Darwin has not changed and is still
/Library/GNUstep/GNUstep.conf regardless of the prefix selected.
`Removed the --with-system-root, --with-local-root and --with-network-root options'
'Removed the --with-system-root, --with-local-root and --with-network-root options'
These configure options were obsolete and are ignored by all
releases in the past 4 years and have now finally been removed.
`Removed obsolete variables'
'Removed obsolete variables'
Some very old variables that were deprecated 4 years ago have now
been removed. This includes xxx_RESOURCE_FILES_INSTALL_DIR in
resource-set.make (you should use xxx_INSTALL_DIR instead) and
GNUSTEP_GSWAPPS in gswapp.make (you should use GNUSTEP_WEB_APPS
instead).
`New Test Framework'
'New Test Framework'
GNUstep-make now includes a test framework that can be used to
easily write testcases for Objective-C software. The new releases
of GNUstep-base and GNUstep-gui include regression test suites
that use this test framework. Please check the README in the
TestFramework directory for more information on how it works or
how to use it.
of GNUstep-base and GNUstep-gui include regression test suites that
use this test framework. Please check the README in the
TestFramework directory for more information on how it works or how
to use it.
`objc.make is deprecated'
'objc.make is deprecated'
The file objc.make, which is used to compile Objective-C
command-line tools without a Foundation library such as GNUstep
base, is now deprecated. Please use tool.make instead.
`--enable-absolute-install-paths is now the default on Darwin'
'--enable-absolute-install-paths is now the default on Darwin'
This makes it easier to use GNUstep with the gnu-gnu-gnu library
combo on Apple Mac OS X.
1.10 Version 2.4.0
==================
1.9 Version 2.4.0
=================
`You can enable the use of the non-fragile ivar ABI'
'You can enable the use of the non-fragile ivar ABI'
The -enable-objc-nonfragile-abi flag can be used to enable the
non-fragile ivar ABI for compilers (such as clang) that support it.
`-Wall is now used by default unless 'make warn=no' is specified'
'-Wall is now used by default unless 'make warn=no' is specified'
Before version 2.4.0, 'make debug=yes' would not only build object
files particularly suited for debugging, but would also add the
-Wall flag on the compiler command line when compiling
@ -157,20 +183,20 @@ Bug fixes
can turn it off by using 'make warn=no'.
A similar change occurred for Java compilations, where the flag
-deprecation, which used to be enabled by debug=yes, is now
enabled by warn=yes. As a consequence, Java code is now compiled
by default with the -deprecation flag. You can turn it off by
-deprecation, which used to be enabled by debug=yes, is now enabled
by warn=yes. As a consequence, Java code is now compiled by
default with the -deprecation flag. You can turn it off by
compiling with 'make warn=no'.
`PACKAGE_NEEDS_CONFIGURE and JAVADOC_BUILD_ALWAYS now support 'yes' and 'no''
'PACKAGE_NEEDS_CONFIGURE and JAVADOC_BUILD_ALWAYS now support 'yes' and 'no''
gnustep-make boolean variables traditionally use the values 'yes'
and 'no', with the unfortunate exception of
PACKAGE_NEEDS_CONFIGURE and JAVADOC_BUILD_ALWAYS which used to
only recognize the values 'YES' and 'NO'. For consistency with
everything else, starting with gnustep-make 2.4.0 these two
variables recognize the values 'yes' and 'no' too.
and 'no', with the unfortunate exception of PACKAGE_NEEDS_CONFIGURE
and JAVADOC_BUILD_ALWAYS which used to only recognize the values
'YES' and 'NO'. For consistency with everything else, starting with
gnustep-make 2.4.0 these two variables recognize the values 'yes'
and 'no' too.
`Versions of GNU make older then 3.79.1 (June 2000) are no longer supported'
'Versions of GNU make older then 3.79.1 (June 2000) are no longer supported'
The .NOTPARALLEL pseudo-target is only available in GNU make 3.79
and is essential for parallel builds to work. Starting with
version 2.4.0, gnustep-make recommends using GNU make 3.79.1 or
@ -180,19 +206,19 @@ Bug fixes
3.79.1 was released about 10 years ago, this should not be a
particular problem.
`new internalmessages=yes option'
'new internalmessages=yes option'
Starting with version 2.4.0, gnustep-make recognized the new
internalmessages=yes option (separate from messages=yes) which
prints all the recursive make invocations that are used. This is
mostly useful to understand how gnustep-make internally works and
is not meant for end-users.
`javadoc is run in quiet mode'
'javadoc is run in quiet mode'
Starting with version 2.4.0, javadoc is by default executed with
the -quiet option (unless messages=yes is specified), and a
"Generating javadoc documentation..." is printed instead.
"Generating javadoc documentation..." is printed instead.
`new API to build subdirectories'
'new API to build subdirectories'
Before version 2.4.0, aggregate.make was used to step into
subdirectories and build them. It did not support parallel
building. Starting with version 2.4.0, two new makefile fragments
@ -209,47 +235,46 @@ Bug fixes
independent of each other. The operations that are executed in
parallel are 'all', 'clean', 'distclean', 'check' and 'strings'.
'install' and 'uninstall' are still executed in serial order to
prevent any concurrency problems when creating (or removing)
common installation directories.
prevent any concurrency problems when creating (or removing) common
installation directories.
aggregate.make is still available if you want or need to be
backwards-compatible with older versions of gnustep-make. It is
normally a wrapper around serial-subdirectories.make, but if you
specify 'GNUSTEP_USE_PARALLEL_AGGREGATE = yes' in your
GNUmakefile, it becomes a wrapper around
parallel-subdirectories.make. aggregate.make will be deprecated
in 2012 and removed in 2015, but for the next couple of years it
might be a good solution while you wait for your users to upgrade
their gnustep-make installations.
specify 'GNUSTEP_USE_PARALLEL_AGGREGATE = yes' in your GNUmakefile,
it becomes a wrapper around parallel-subdirectories.make.
aggregate.make will be deprecated in 2012 and removed in 2015, but
for the next couple of years it might be a good solution while you
wait for your users to upgrade their gnustep-make installations.
`each instance stores object files in its own subdirectory'
'each instance stores object files in its own subdirectory'
Before version 2.4.0, there was a single object directory where all
object files where stored. In the most common case, this directory
was simply ./obj, so if you compiled file source.m, you'd end up
with ./obj/source.m.o. Starting with version 2.4.0, different
instances store their object files in different subdirectories;
for example, if the file was compiled as part of tool ToolA, it
would end up in ./obj/ToolA.obj/source.m.o, while if compiled as
part of ToolB, it would end up in ./obj/ToolB.obj/source.m.o.
This allows ToolA and ToolB to be built in parallel with no race
conditions, even if they share some source files. There are a
number of side effects of this change. First of all, in the
unlikely event that your GNUmakefile depends on the location of
the object files (bad idea by the way), you'll have to update it.
Second, if you are reusing a single source file in multiple
instances in the same project, this will now be compiled multiple
times instead of one (on the plus side, you can fully parallelize
the build by just using 'make -j N', without having to change
anything in your GNUmakefile. On a machine with multiple
cpus/cores this can massively speed up the build). Finally, the
rules to compile C/ObjC/C++/ObjC++/Windres files are no longer
available in the Master invocation - they are only available when
compiling a specific instance. It's hard to imagine a situation
where this change of private internals would affect any user; but
people with their own private gnustep-make forks or advanced
extensions might be affected.
instances store their object files in different subdirectories; for
example, if the file was compiled as part of tool ToolA, it would
end up in ./obj/ToolA.obj/source.m.o, while if compiled as part of
ToolB, it would end up in ./obj/ToolB.obj/source.m.o. This allows
ToolA and ToolB to be built in parallel with no race conditions,
even if they share some source files. There are a number of side
effects of this change. First of all, in the unlikely event that
your GNUmakefile depends on the location of the object files (bad
idea by the way), you'll have to update it. Second, if you are
reusing a single source file in multiple instances in the same
project, this will now be compiled multiple times instead of one
(on the plus side, you can fully parallelize the build by just
using 'make -j N', without having to change anything in your
GNUmakefile. On a machine with multiple cpus/cores this can
massively speed up the build). Finally, the rules to compile
C/ObjC/C++/ObjC++/Windres files are no longer available in the
Master invocation - they are only available when compiling a
specific instance. It's hard to imagine a situation where this
change of private internals would affect any user; but people with
their own private gnustep-make forks or advanced extensions might
be affected.
`the order in which instances are built is no longer guaranteed'
'the order in which instances are built is no longer guaranteed'
If you build more than one tool in the same GNUmakefile by listing
them all in TOOL_NAME as in "TOOL_NAME = ToolA ToolB', you need to
be aware that the way the instances are built changed in version
@ -258,11 +283,11 @@ Bug fixes
This change affects applications, bundles, ctools, clibraries,
libraries, services, palettes, test-applications, test-libraries,
test-tools, tools. It does not affect Java, resource sets or
documentation. [FIXME: frameworks ?]
documentation. [FIXME: frameworks ?]
Before version 2.4.0, instances were always built one after the
other one, exactly in the order specified. So, in the example
ToolA would be built before ToolB. Starting with 2.4.0, the
ToolA would be built before ToolB. Starting with 2.4.0, the
instances might be built completely in parallel if parallel
building is enabled. So, the order in which they are built is no
longer defined and your GNUmakefile should not depend on the order
@ -291,17 +316,17 @@ Bug fixes
built before the tool (or tools). It is the order in which the
libraries (or tools) are built that is no longer guaranteed.
`support for having source files in subdirectories'
'support for having source files in subdirectories'
Starting with version 2.4.0, it is possible to put source files in
subdirectories by specifiying them as in xxx_OBJC_FILES =
Source/Beauty.m. This syntax does not work on versions before
2.4.0 so you should not use it if you want to support older
versions of gnustep-make; previously you had to create a
subproject and add a GNUmakefile in the subdirectory using
subproject.make. You can now spread your source files in multiple
subdirectories without using subprojects.
versions of gnustep-make; previously you had to create a subproject
and add a GNUmakefile in the subdirectory using subproject.make.
You can now spread your source files in multiple subdirectories
without using subprojects.
`support for having header files in subdirectories'
'support for having header files in subdirectories'
Starting with version 2.4.0, it is possible to put header files in
subdirectories by specifiying them as in xxx_HEADER_FILES =
Beauty/Beauty.h. This syntax does not work on versions before
@ -314,7 +339,7 @@ Bug fixes
the same result in versions before 2.4.0 you would have had to
manually create the header installation subdirectories.
`support for HEADER_FILES_DIR in framework subproject'
'support for HEADER_FILES_DIR in framework subproject'
Before version 2.4.0, specifying xxx_HEADER_FILES_DIR in a
framework subproject would have no effect. Starting with version
2.4.0, the variable is now recognized and can be used to have the
@ -322,49 +347,49 @@ Bug fixes
framework subprojects if you want to support older versions of
gnustep-make.
`info files renamed adding a gnustep- prefix'
'info files renamed adding a gnustep- prefix'
To prevent conflicts with other documentation, all the gnustep-make
info files have been renamed adding a gnustep- prefix. For
example, to access the GNUstep faq using info, you now need to
type 'info gnustep-faq' instead of 'info faq'. Please note that
this info documentation is in the core/make/Documentation
subdirectory and at the moment is not automatically installed
unless you explicitly go in that subdirectory and install it.
example, to access the GNUstep faq using info, you now need to type
'info gnustep-faq' instead of 'info faq'. Please note that this
info documentation is in the core/make/Documentation subdirectory
and at the moment is not automatically installed unless you
explicitly go in that subdirectory and install it.
`better cleaning for texinfo documentation'
'better cleaning for texinfo documentation'
When you build html documentation from texinfo files, the local
directory containing the html files was not being removed when
doing a 'make clean'. Starting with version 2.4.0, 'make clean'
removes the directory too.
`debug=no made the default'
'debug=no made the default'
gnustep-make now builds using debug=no by default. As a
consequence, on most platforms C/Objective-C/C++ code is now built
by default using -g -O2 instead of just -g. If you do not want
the -O2 flag, you can simply build using 'make debug=yes'. You
can also use the new ./configure -enable-debug-by-default option
to make 'debug=yes' the default flag that is always used when
by default using -g -O2 instead of just -g. If you do not want the
-O2 flag, you can simply build using 'make debug=yes'. You can
also use the new ./configure -enable-debug-by-default option to
make 'debug=yes' the default flag that is always used when
compiling if nothing else is specified. If you do not want the
debugging symbols, remember that you can use the 'make strip=yes'
option to have them stripped out from all object files when they
are installed.
`batch-compilation of Java files'
'batch-compilation of Java files'
gnustep-make used to compile Java files one by one. In most Java
compilers this is very suboptimal. Starting from release 2.4.0,
gnustep-make will compile all Java files in a Java project with a
single Java compiler invocation. This can significantly speed up
compilation of large projects. To disable it and get the
behaviour of gnustep-make 2.2.0, please set the variable
compilation of large projects. To disable it and get the behaviour
of gnustep-make 2.2.0, please set the variable
BATCH_COMPILE_JAVA_FILES to 'no' (or the variable
xxx_BATCH_COMPILE_JAVA_FILES to 'no' to disable it for a single
instance). Please note that if you are using the xxx_FILE_FLAGS
or xxx_FILE_FILTER_OUT_FLAGS functionality for Java files, which
instance). Please note that if you are using the xxx_FILE_FLAGS or
xxx_FILE_FILTER_OUT_FLAGS functionality for Java files, which
allows you to customize the compilation flags for each Java file,
then batch compilation is automatically disabled and all files are
compiled separately.
`library resources always installed in directory without 'lib''
'library resources always installed in directory without 'lib''
This change only applies to libraries where LIBRARY_NAME starts
with 'lib' and that install resources. Due to a bug, versions of
gnustep-make before 2.4.0 would in this case install the resources
@ -376,28 +401,28 @@ Bug fixes
GNUSTEP_LIBRARY/Libraries/gnustep-base/Versions/1.14/Resources/.
In gnustep-make 2.4.0, this bug has been fixed and the library
name, without 'lib', will always be used in the resource
installation directory, no matter if LIBRARY_NAME includes 'lib'
or not.
installation directory, no matter if LIBRARY_NAME includes 'lib' or
not.
If you have a makefile which is affected and you need to support
older versions of gnustep-make, you could remove 'lib' from the
LIBRARY_NAME. That should install resources in the same directory
LIBRARY_NAME. That should install resources in the same directory
on all gnustep-make versions that support library resources (ie,
gnustep-make >= 2.0.x).
1.10 Version 2.2.0
1.11 Version 2.2.0
==================
`libobjc library'
'libobjc library'
You can now specify a particular libobjc library to use with the
-with-objc-lib-flag in configure. Make now also automatically uses
-lobjc_gc when using garbage collection.
`parallel building'
Parallel building is supported now. You can build using the
normal make mechanism, e.g. 'make -j 2'.
'parallel building'
Parallel building is supported now. You can build using the normal
make mechanism, e.g. 'make -j 2'.
`install -p'
'install -p'
gnustep-make now uses 'install -p' by default when installing
headers and other files. This preserves the file timestamps and
can in some cases reduce spurious rebuilds triggered by
@ -405,16 +430,15 @@ Bug fixes
gnustep-make configure option -disable-install-p to disable this
behaviour and go back to always using a standard 'install'.
`uninstallation of resources'
'uninstallation of resources'
gnustep-make now is more careful and accurate when uninstalling
resources, which means that 'make uninstall' will do a better job
at removing directories that were created during by 'make install'.
1.11 Version 2.0.7
1.12 Version 2.0.7
==================
`default installation'
'default installation'
New configuration file that allows hardcore developers building
everything from source to specify arbitrary default installation
domains for the software. You just need to copy the
@ -422,81 +446,79 @@ Bug fixes
GNUstep.conf file, and edit it to customize the default
installation domain (Thanks to Richard for the idea).
`--no-print-directory'
'--no-print-directory'
gnustep-make now uses the -no-print-directory flag when invoking
make recursively, so the output has changed - starting from 2.0.7
it should be shorter and more readable.
`change to intermediate object file names'
'change to intermediate object file names'
gnustep-make now supports having in the same project source files
with the same name, but a different extension - for example file.c
and file.m. The names of intermediate object files have been
internally changed (for example, from file.o to file.c.o) to
support this.
`change in path checking algorithm in GNUstep.sh and GNUstep.csh'
'change in path checking algorithm in GNUstep.sh and GNUstep.csh'
GNUstep.sh and GNUstep.csh perform more careful checks for
duplicate paths when adding paths to PATH and other path
variables. Now they check each path separately before adding it,
which in some cases will produce smaller and less intrusive
additions to PATH; in particular, on FHS filesystem layout, they
will never add /usr/bin or other system paths if they are already
there. If you are in a situation where there is an overlap
between GNUstep paths and system paths and you are using
GNUstep.sh or GNUstep.csh, you may want to check the new values of
PATH, CLASSPATH, GUILE_LOAD_PATH, INFOPATH, LD_LIBRARY_PATH and
similar variables since they may be different from the old ones.
duplicate paths when adding paths to PATH and other path variables.
Now they check each path separately before adding it, which in some
cases will produce smaller and less intrusive additions to PATH; in
particular, on FHS filesystem layout, they will never add /usr/bin
or other system paths if they are already there. If you are in a
situation where there is an overlap between GNUstep paths and
system paths and you are using GNUstep.sh or GNUstep.csh, you may
want to check the new values of PATH, CLASSPATH, GUILE_LOAD_PATH,
INFOPATH, LD_LIBRARY_PATH and similar variables since they may be
different from the old ones.
`test applications linked against gnustep-gui by default'
'test applications linked against gnustep-gui by default'
Test applications (that is, applications created using
test-application.make) are now linked against gnustep-gui by
default.
1.12 Version 2.0.6
1.13 Version 2.0.6
==================
`GNUSTEP_ABSOLUTE_INSTALL_PATHS'
'GNUSTEP_ABSOLUTE_INSTALL_PATHS'
Added the -enable-absolute-install-paths option to configure on
Darwin. Enabling this option modifies the process for building
dynamic libraries so the install_name stored within a library is
an absolute path. Dynamic libraries with an absolute install_name
can be placed in non-standard locations, but may not be moved from
dynamic libraries so the install_name stored within a library is an
absolute path. Dynamic libraries with an absolute install_name can
be placed in non-standard locations, but may not be moved from
their designated location.
`default location of GNUstep.conf on BSD systems'
'default location of GNUstep.conf on BSD systems'
This has been changed to /etc/GNUstep/GNUstep.conf to be consistent
across all Unix systems (except for Apple Mac OS X where it is
installed in /Library/GNUstep/GNUstep.conf). To install in a
different location, use the -with-config-file=PATH option, as in
-with-config-file=/usr/pkg/etc/GNUstep.conf.
`make.info renamed to gnustep-make.info'
'make.info renamed to gnustep-make.info'
To prevent conflicts with the standard GNU 'make' info
documentation, the gnustep-make one has been renamed. Now you can
access it as in 'info gnustep-make' instead of 'info make',
avoiding any conflicts and confusion. Please note that this info
documentation is in the core/make/Documentation subdirectory and
at the moment is not automatically installed unless you explicitly
go in that subdirectory and install it.
documentation is in the core/make/Documentation subdirectory and at
the moment is not automatically installed unless you explicitly go
in that subdirectory and install it.
1.13 Version 2.0.5
1.14 Version 2.0.5
==================
`default filesystem layout on apple-apple-apple'
'default filesystem layout on apple-apple-apple'
The default filesystem layout when using the apple-apple-apple
library-combo has been changed from 'gnustep' to the new 'apple'
filesystem layout, and on darwin the configuration file is by
default installed in /Library/GNUstep/GNUstep.conf instead of
/etc/GNUstep/GNUstep.conf. Using the 'gnustep' filesystem layout
with the apple-apple-apple library-combo did not make much sense;
in gnustep-make version 2.0.5 and newer, a ./configure on Apple
Mac OS X automatically chooses the right library-combo and
filesystem layout to compile and install Apple native frameworks
and applications.
in gnustep-make version 2.0.5 and newer, a ./configure on Apple Mac
OS X automatically chooses the right library-combo and filesystem
layout to compile and install Apple native frameworks and
applications.
`~/GNUstep/GNUstep.sh'
'~/GNUstep/GNUstep.sh'
This script used to be automatically sourced whenever the main
GNUstep.sh file was sourced. In gnustep-make version 2 (starting
with 2.0.5) the file is no longer sourced. If you are sourcing
@ -505,7 +527,7 @@ Bug fixes
shell init script before or after sourcing GNUstep.sh. The same
applies to ~/GNUstep/GNUstep.csh.
`xxx_NEEDS_GUI'
'xxx_NEEDS_GUI'
This new variable can be used to specify that a project needs to be
linked against the gui library (or not). If set to yes, the gui
library will be linked; if set to no, the gui library will not be
@ -517,27 +539,26 @@ Bug fixes
xxx_NEEDS_GUI for all bundles, frameworks and libraries to clarify
how the linking should be done.
`NEEDS_GUI'
'NEEDS_GUI'
This new variable can be used to specify that all projects built by
this GNUmakefile need to be linked against the gui library (or
not). If set to yes, the gui library will be linked; if set to
no, the gui library will not be linked. This behaviour can be
not). If set to yes, the gui library will be linked; if set to no,
the gui library will not be linked. This behaviour can be
overridden for specific project targets by using the xxx_NEEDS_GUI
variable (see above).
1.14 Version 2.0.0
1.15 Version 2.0.0
==================
Version 2.0.0 is a new major release of gnustep-make which includes a
number of major changes compared to previous 1.x releases. Most of the
changes are backwards compatible in the sense that old GNUmakefiles
will work with gnustep-make version 1 or 2 when used in the same
conditions (traditional GNUstep filesystem layout). But GNUmakefiles
might need updating to work with the new filesystem layout
configurations that are allowed by gnustep-make version 2.
changes are backwards compatible in the sense that old GNUmakefiles will
work with gnustep-make version 1 or 2 when used in the same conditions
(traditional GNUstep filesystem layout). But GNUmakefiles might need
updating to work with the new filesystem layout configurations that are
allowed by gnustep-make version 2.
`GNUSTEP_INSTALLATION_DIR'
'GNUSTEP_INSTALLATION_DIR'
This variable is deprecated in gnustep-make version 2; you should
never use it. gnustep-make version 2 supports installation domains
that are mapped to filesystem locations in arbitrary ways; for this
@ -545,27 +566,26 @@ configurations that are allowed by gnustep-make version 2.
sense. If you need to relocate the whole installation (for
example, installing into /tmp to prepare a binary package) you
should use DESTDIR, as in 'make install DESTDIR=/tmp'. To choose
an installation domain, you should use
GNUSTEP_INSTALLATION_DOMAIN, as in 'make install
GNUSTEP_INSTALLATION_DOMAIN=LOCAL'. It's particularly important
that you remove any reference to GNUSTEP_INSTALLATION_DIR inside
your own GNUmakefiles.
an installation domain, you should use GNUSTEP_INSTALLATION_DOMAIN,
as in 'make install GNUSTEP_INSTALLATION_DOMAIN=LOCAL'. It's
particularly important that you remove any reference to
GNUSTEP_INSTALLATION_DIR inside your own GNUmakefiles.
If your GNUmakefiles contains references to
GNUSTEP_INSTALLATION_DIR (or similar), you should remove them by
replacing them with references to the actual logical directory
into which you want to install. For example, if your GNUmakefile
is trying to install something into
replacing them with references to the actual logical directory into
which you want to install. For example, if your GNUmakefile is
trying to install something into
GNUSTEP_INSTALLATION_DIR/Library/Libraries, you need to replace it
with GNUSTEP_LIBRARIES. This is important for non-GNUstep
with GNUSTEP_LIBRARIES. This is important for non-GNUstep
filesystem layouts (where, eg, GNUSTEP_LIBRARIES should be set to
/usr/lib or /usr/local/lib or
/home/nicola/GNUstep/Library/Libraries depending on the
installation domain); in that case, gnustep-make will manage
GNUSTEP_LIBRARIES for you. Please check the file `filesystem' for
GNUSTEP_LIBRARIES for you. Please check the file 'filesystem' for
more information on the available variables.
`GNUSTEP_xxx_ROOT'
'GNUSTEP_xxx_ROOT'
The variables GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT,
GNUSTEP_NETWORK_ROOT, GNUSTEP_USER_ROOT and GNUSTEP_ROOT are
deprecated in gnustep-make version 2 and you should never use them.
@ -578,10 +598,10 @@ configurations that are allowed by gnustep-make version 2.
to the actual logical directory into which you want to install.
For example, if your GNUmakefile is trying to install something
into GNUSTEP_SYSTEM_ROOT/Library/Libraries, you need to replace it
with GNUSTEP_SYSTEM_LIBRARIES. Please check the file `filesystem'
with GNUSTEP_SYSTEM_LIBRARIES. Please check the file 'filesystem'
for more information on the available variables.
`gnustep-make ./configure and install options'
'gnustep-make ./configure and install options'
The options to configure (and make install), particularly the ones
to determine the filesystem layout, have been radically changed in
gnustep-make version 2. If you have a building or packaging script
@ -591,66 +611,64 @@ configurations that are allowed by gnustep-make version 2.
configure options have been replaced by the more powerful
-with-layout configure option. Also, configure no longer imports
an existing configuration file so you need to make sure that you
pass all the options every time. 'make install
special_prefix=xxx' has been replaced by 'make install
DESTDIR=xxx'.
pass all the options every time. 'make install special_prefix=xxx'
has been replaced by 'make install DESTDIR=xxx'.
`make debug=yes is now the default'
'make debug=yes is now the default'
The default used to be 'make debug=no'; this has now been changed
to be 'make debug=yes'. To get the traditional behaviour, please
use 'make debug=no'.
`RPM support rewritten'
'RPM support rewritten'
The RPM support has been rewritten so if you're using gnustep-make
to automatically generate RPM packages for your software, you may
want to review the process. In particular, there is no longer a
distinction between debug and non-debug packages.
`xxx_PREPROCESS_INFO_PLIST'
'xxx_PREPROCESS_INFO_PLIST'
This variable is now obsolete and can be removed; gnustep-make
version 2 can automatically detect plists that need preprocessing.
`Framework default version'
'Framework default version'
The default framework resource version changed from 'A' to
INTERFACE_VERSION (which is set, by default, to '0').
`Microsoft Windows updates'
'Microsoft Windows updates'
If you are using Microsoft Windows, you probably want to check the
new installation instructions and reinstall everything.
`Java tools location changed'
'Java tools location changed'
Java tools are now installed into GNUSTEP_JAVA rather than in a
subdirectory of GNUSTEP_TOOLS.
`resource-set.make install directory'
'resource-set.make install directory'
The variable xxx_RESOURCE_FILES_INSTALL_DIR for resource-set.make
has been deprecated in favour of xxx_INSTALL_DIR. For backwards
has been deprecated in favour of xxx_INSTALL_DIR. For backwards
compatibility, you may want to set them both:
xxx_INSTALL_DIR = $(GNUSTEP_LIBRARY)/Libraries/Resources/xxx
xxx_RESOURCE_FILES_INSTALL_DIR = /Library/Libraries/Resources/xxx
`INSTALL_ROOT_DIR'
'INSTALL_ROOT_DIR'
All instances of INSTALL_ROOT_DIR in user's makefiles should be
replaced with DESTDIR.
`GNUSTEP_FLATTENED'
'GNUSTEP_FLATTENED'
All checks for GNUSTEP_FLATTENED should be updated to check the new
variable GNUSTEP_IS_FLATTENED instead, and to compare it
explicitly to 'yes' and 'no', and assume that " means 'yes'.
variable GNUSTEP_IS_FLATTENED instead, and to compare it explicitly
to 'yes' and 'no', and assume that " means 'yes'.
`./shared_obj'
The ./shared_obj, ./shared_debug_obj directories and similar are
no longer created. You can use ./obj instead.
'./shared_obj'
The ./shared_obj, ./shared_debug_obj directories and similar are no
longer created. You can use ./obj instead.
`library names'
'library names'
All libraries now have the same name.
`application names'
'application names'
All applications now have the same name.
Copyright (C) 2007 Free Software Foundation
Copying and distribution of this file, with or without modification,