The directory layout has changed similarly to that of the gcc 2 couple,
i.e. we install in develop/tools[/<arch>] instead of separate
subdirectories, so gcc finds the matching gas and ld.
Only tested the secondary architecture build so far.
* The files are no longer installed in a separate develop/tools
subdirectory for binutils and one for gcc. Instead we install
directly in develop/tools[/<arch>]. This allows gcc to find gas and
ld via its built-in search instead of via PATH only. In a hybrid
setup this makes a difference, when the gcc that is not the first in
PATH is invoked directly (e.g. via absolute path).
* Add support for building for the secondary architecture. Not tested
yet.
* prerequire cmd:gcc and cmd:ld
* use bootstrap.sh to bootstrap the build system, otherwise it fails to
generate aclocal from aclocal.in (which seems to be related to
timestamps, as an otherwise identical source folder [from the tree]
works fine) - hohum ...
* Rename version: 2.5_121012 -> 2.5_2012_10_12.
* Don't put Jambase.html, Jamfile.html into development directory.
While correct in principle, it is not so nice to separate them from
Jam.html, which is mostly development documentation as well
(documenting the tool invocation and the Jam language).
* Fix incorrect gccDate.
* For the source package only export legacy/gcc.
* architecture -> targetArchitecture
* Add missing provides for c++filt and i586-pc-haiku-gcc.
* Remove libiberty, move libbfs and libocodes to develop/lib.
* For the source package export only legacy/binutils.
* Change documentation directory to $docDir-$version.
* liberate requirement on automake from 1.11 to generic, as there's hope
that any automake equal or newer than 1.11 will do
* add patch for removing dependency to help2man which is being invoked
to regenerate the manpages, which won't work and has become an error
with automake-1.13
* move patches for 2.4 into a corresponding subfolder
* explictly list patches
* strip debug info from all binaries
* based on architecture, decide whether or not to link the tools into
the default path
* use relative symlinks instead of absolute ones, as the latter won't work
when building gcc with itself (in which case the .self-symlink in the
/packages folder will point to the packaging path, where no binaries
exist yet)
available via standard paths. This makes only sense for the default compiler,
but we currently can't tell haikuporter if the one being built is such a
beast.
I suppose we need some kind of feature mechanism for ports in order to be
able to enable/disable stuff like this from the outside.
