This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Ok? Top-level Makefile.in archiver change
- To: ac131313 at cygnus dot com
- Subject: Re: Ok? Top-level Makefile.in archiver change
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 12 Apr 2000 09:15:17 -0700
- CC: binutils at sourceware dot cygnus dot com, newlib at sourceware dot cygnus dot com, gdb-patches at sourceware dot cygnus dot com
- References: <38F42688.41546136@cygnus.com>
Date: Wed, 12 Apr 2000 17:32:24 +1000
From: Andrew Cagney <ac131313@cygnus.com>
The attatched patch re-aranges the way the top level Makefile.in creates
a release (e.g. make -f Makefile.in binutils.tar.bz). Namely, it splits
the process into two more evenly balanced steps:
o do-proto-toplev
o do-tar-bz2
The rewritten taz target then just calls on each of those in turn. By
doing that I can more easily slip in a few extra steps (so far just
do-md5sum) for the GDB release process.
Personally, I would just add the md5sum to the generic release target.
I don't know why anybody would not want that. It's not like the
release targets are carefully thought out; they are just hacked
together to do whatever is needed. I always had to change them for
each release anyhow.
But your patch is OK with me.
+ gdb-taz: $(DEVO_SUPPORT) $(SUPPORT_FILES) texinfo/texinfo.tex
+ $(MAKE) -f Makefile.in do-proto-toplev do-md5sum do-tar-bz2 \
I'm not 100% sure that make promises to execute targets in precisely
the order in which appear in the command line. This is particularly
questionable when using make -j. If you are sure this is correct,
then it is fine with me. Otherwise, it may be better to separate this
into three different make commands.
Ian