Ok? Top-level Makefile.in archiver change

Andrew Cagney ac131313@cygnus.com
Wed Apr 12 19:17:00 GMT 2000

Ian Lance Taylor wrote:
>    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.

I've made the generation of md5.sum part of taz:

> 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.

I'm not sure its safe so I've broken it down into separate steps.


More information about the Newlib mailing list