This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: RFC/RFT: split up pexecute.c
> Okay. What do you think of this patch?
Some minor nits, and a few changes, but looks good so far.
> - partition.c pexecute.c putenv.c \
> + partition.c \
> + pex-cygwin.c pex-djgpp.c pex-mpw.c pex-msdos.c pex-os2.c \
> + pex-unix.c pex-win32.c \
> + putenv.c \
Nit: I indent each line that is a continuation of the same starting
letter by an extra space. So, the two pex-* lines should have the
extra indent (tab+space instead of just tab).
> + pex-cygwin.o pex-djgpp.o pex-mpw.o pex-msdos.o pex-os2.o \
> + pex-unix.o pex-win32.o \
Same nit here.
> cplus-dem.o: config.h $(INCDIR)/ansidecl.h $(INCDIR)/demangle.h \
> - $(INCDIR)/getopt.h $(INCDIR)/libiberty.h $(INCDIR)/safe-ctype.h
> + $(INCDIR)/libiberty.h $(INCDIR)/safe-ctype.h
This change is not documented in your ChangeLog and if desired should
be submitted independently of the pex change.
> -make-relative-prefix.o: config.h $(INCDIR)/ansidecl.h $(INCDIR)/libiberty.h
> +make-relative-prefix.o: config.h $(INCDIR)/ansidecl.h \
> + $(INCDIR)/libiberty.h
Likewise.
> -pexecute.o: config.h $(INCDIR)/ansidecl.h $(INCDIR)/libiberty.h \
> - $(INCDIR)/safe-ctype.h
> +pex-msdos.o: $(INCDIR)/safe-ctype.h
All pex-* depend on libiberty.h, ansidecl.h, and config.h. They
should all be listed here. Did you use the maint-deps Makefile target
to update the dependencies, or do them manually?
> Index: pex-common.h
> +/* pexecute: execute a program.
> +
> + @deftypefn Extension int pexecute (const char *@var{program}, char * const *@var{argv}, const char *@var{this_pname}, const char *@var{temp_base}, char **@var{errmsg_fmt}, char **@var{errmsg_arg}, int flags)
gather-docs only looks at *.c and *.texi, not at *.h. You should
create a pexecute.texi to put the documentation in, and update TEXISRC
in Makefile.in.
> +#include "pex-common.h"
> +
> +#include <stdio.h>
Do we really want to put libiberty-specific headers (libiberty.h0
before system headers? IMHO it's better to always do system headers
first (except for config.h, of course).