gcc-3.2 DESTDIRified

[Christian Cornelssen <ccorn at cs dot tu-berlin dot de>]

Dear GCC maintainers,

On Fri, 22 Mar 2002, Christian Cornelssen wrote:

in order to ease making binary RPMs, I have added DESTDIR support to the
gcc-3.2 suite.  It enables the user to do a "make DESTDIR=/some/tmp/dir
install" and thus redirect any install destination from /path to
/some/tmp/dir/path without having to change any of the configured
`xxxdir' variables.  This concept has already been supported by those
parts of the distribution that are under control auf Automake (i.e. have
`Makefile.am's).  I have modified the remaining parts of the full GCC
distribution to complete the support.

Note that the usual alternative of changing `prefix' and/or some
`xxxdir' variables does not work completely for some reason.  When it
came to libgcj (IIRC), the configured values were used, ignoring the
top-level command-line arguments, even though I use GNU Make.

Besides, changing prefix directly can be dangerous because if for any
reason sources are recompiled in the course of the installation, the
bogus path may get into the binaries, which is not desirable.

The Patch consists of the following attached files:

1. `gcc-3.2-destdir.diff' modifies all Makefile sources except
   `Makefile.am's

2. `gcc-3.2-destdir-am.diff' modifies custom installation rules of
   `Makefile.am's.  You will have to run a suitable version of Automake
    after patching, or apply the following:

3. `gcc-3.2-destdir-no-am.diff' which modifies the Automake-generated
   `Makefile.in's directly.  This is for users who do not have the
   intended version of Automake, or for packaging tools like RPM which
   shall not require the Autotools.  In both cases, applying the above
   `gcc-3.2-destdir-am.diff' should be avoided, otherwise "make" could
   trigger the autoreconfiguration anyway.

The patches are in GNU unified format, intended to be piped to
"patch -p0" within the top directory of the GCC suite.

Additional attachments:

4. `scaninst.pl', a perl script for heuristic verification of the
   DESTDIR support in the Makefile sources, see below.

5. `gcc3.spec', an RPM spec file for gcc-3.2.  It's not perfect, but
   should provide a starting point for other packagers.  You might want
   to have a look at it because it contains some additional workarounds.

Notes:

- I have followed Automake's style in directly modifying the ultimate
  installation commands by prepending $(DESTDIR) to the destination
  specifiers.  Also like newer Automakes, I have not defined a default
  value for DESTDIR in any `Makefile.in', in order to let Make import
  that variable from the environment and thus share it with sub-makes.
  Additionally, I have added "DESTDIR=$(DESTDIR)" to the FLAGS_TO_PASS
  variables defined in some `Makefile.in's.

- I have taken care to make the $(DESTDIR) magic work with all choices
  for $(LN).  In some places this required replacing absolute linking
  like "$(LN) $(bindir)/xxx $(bindir)/yyy" by relative linking as in
  "(cd $(DESTDIR)$(bindir) && $(LN) xxx yyy)".

- Where perhaps necessary, I have improved the directory creating
  routines from a series of conditional mkdirs to a smarter loop.

- Some routines (in `gcc/{ada,cp}/Make-lang.in' and `gcc/Makefile.in')
  try to be smart and duplicate executables into additional tooldirs if
  these exist.  The patches also redirect the tests, so packagers who
  want to have tooldir stuff have to create the tooldirs in the DESTDIR
  tree before doing a DESTDIRed install.  I prefer this approach because
  it lets the packager control that detail independent of the situation
  on the particular build host.  (In SuSE Linux, the tooldirs seem to be
  solely used by the binutils.)  The scenario would be the same for
  non-redirected installs into an own new tree such as /opt/gcc3, so I
  think this is what one should expect.

  The alternative would be: Test for host's tooldir as before, then
  create its DESTDIRed analogue if necessary (new), and do the DESTDIRed
  installation.  This may be more or less convenient than the above
  approach, but it cannot be influenced by the packager.

- I have developed a Perl5 script `scaninst.pl' that detects Makefile
  fragments that are likely to need DESTDIR support added.  I have used
  it myself to scan the large source tree, and I have tuned it to make
  it find all instances that needed changing while discarding almost all
  others.  The script works by looking for commands using plain
  $(prefix), $(foo_prefix), $(foodir) etc, while discarding those where
  I have found the foodir to define a buildtree subdirectory.  When the
  script finds a command of concern, it displays the source file's name
  and the detected fragment (actually the containing command with all
  backslash-continued lines).

  A typical usage looks like:

	find -name mybuilddir -prune -o \
	\( -name '*.in' -o -name 'Makefile*' -o -name 't-*' \) \
	! -name '*.orig' -print | xargs -r scaninst.pl | less -S

  This script will help you to find the places that may need fixing, in
  cases where my patches are out of date, or incomplete because of
  recent additions.

  `scaninst.pl' ignores foodirs that I found to be non-installdirs.
  You might instead want to look for known installdirs.  Well, after
  my patches were done, I rescanned the tree for `DESTDIR' with

	find -name mybuilddir -prune -o \
	\( -name '*.in' -o -name 'Makefile*' -o -name 't-*' \) \
	! -name '*.orig' -print | xargs -r perl -ne \
	'while (/\$+[{(]DESTDIR[)}](\$+[{(]?\w*[)}]?)/g)
		{print $1, "\n";} # or $&' | sort -u | column

  and found that one has to look for commands accessing

	$$(slibdir)			$(libdir)
	$(bindir)			$(libsubdir)
	$(datadir)			$(localedir)
	$(gcc_tooldir)			$(man1dir)
	$(gcjdir)			$(man7dir)
	$(gettextsrcdir)		$(prefix)
	$(glibcpp_toolexeclibdir)	$(secdir)
	$(glibcppinstalldir)		$(tooldir)
	$(hackdir)			$(toolexeclibdir)
	$(includedir)			$(toolgcjdir)
	$(infodir)			${gxx_include_dir}
	$(jardir)

  But this list could have grown, therefore I recommend checking with
  `scaninst.pl' anyway.

- While fixing `libstdc++-v3/include/Makefile.am', I encountered a
  couple of mkinstalldir commands unused by subsequent installation
  commands.  In the latter, I changed the installation destination to
  use the previously made subdir, and then found that that subdir
  evaluates to `.' anyway, so there is no actual change of behaviour.

  Besides, the install-local rule could easily be replaced by a series
  of xxxincludedir and corresponding xxxinclude_HEADERS declarations.
  This would be cleaner, shorter, would need no fixing, and would even
  support uninstalling.

- `scaninst.pl' also displayed installations to $(locale_installdir) in
  `libstdc++-v3/po/Makefile.am'.  These did not need fixing because the
  definition of locale_installdir itself contains a $(DESTDIR) prefix.
  Therefore, I did not change this, but notice that this is uncommon
  style.

You may remember that I had also exercised this with the gcc-3.0.4
release.  There, Joseph S. Meyers replied that the patch could not be
merged into the current branch (although I had also supplied the
script), and that a copyright assignment would be needed for a
contribution of that size (although it's essentially just some hundred
insertions of `$(DESTDIR)').  Furthermore, the new feature would have to
be mentioned in the docs.  But I did not want to have additional work,
and checking out GCC via 56k modem is really no fun, therefore I dropped
the idea of contributing to GCC.  However, when I found the time to make
RPMs of the 3.2 release, I had to redo all the patching, and I am
getting tired of this.  If you do not want to adapt changed Makefile
sources yourself, you could at least provide me with an up-to-date list
of the files that need scrutinizing, so that I do not need to check out
the entire GCC tree.  The above "find" command might suffice.

Anyway, I'll share the patches with RPM distributors such that they can
use it until the next GCC release must be packaged.

Best regards,

Christian Cornelssen <ccorn@cs.tu-berlin.de>

Attachment: gcc-3.2-destdir.diff
Description: Text document

Attachment: gcc-3.2-destdir-am.diff
Description: Text document

Attachment: gcc-3.2-destdir-no-am.diff
Description: Text document

Attachment: scaninst.pl
Description: Perl program

Attachment: gcc3.spec
Description: Text document