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.
thanks,
Andrew
More information about the Newlib
mailing list