[RFC] Replicate src dir in build dir

  Simon Marchi <simon.marchi@polymtl.ca> writes:

> I'm always a bit uncomfortable with putting some rm -rf commands in
> scripts, if we can avoid it.  Can we replace that with rmdir, since
> the clean target should have emptied that directory just before?
>
> Also I wouldn't silence the commands (the @), it's always good to be
> able to read what's being executed.
>

OK, I'll change to rmdir and remove @.

>>
>>  maintainer-clean: local-maintainer-clean do-maintainer-clean distclean
>>  realclean: maintainer-clean
>> @@ -2941,9 +2949,9 @@ ifeq ($(DEPMODE),depmode=gcc3)
>>  # into place if the compile succeeds.  We need this because gcc does
>>  # not atomically write the dependency output file.
>>  override COMPILE.post = -c -o $@ -MT $@ -MMD -MP \
>> -	-MF $(DEPDIR)/$(basename $(@F)).Tpo
>> -override POSTCOMPILE = @mv $(DEPDIR)/$(basename $(@F)).Tpo \
>> -	$(DEPDIR)/$(basename $(@F)).Po
>> +	-MF $(@D)/$(DEPDIR)/$(@F).Tpo
>> +override POSTCOMPILE = @mv $(@D)/$(DEPDIR)/$(@F).Tpo \
>> +	$(@D)/$(DEPDIR)/$(@F).Po
>>  else
>>  override COMPILE.pre = source='$<' object='$@' libtool=no \
>>  	DEPDIR=$(DEPDIR) $(DEPMODE) $(depcomp) $(CC)
>
> I have never tested it, but I assume the "depcomp" mode of dependency
> management will have to be updated too.

I don't understand this comment.  The only change in on dependency
tracking is that .Po file is moved to a new place (.deps/amd64.Po ->
./arch/.deps/amd64.o.Po).  The file contents don't change.

$ diff -u .deps/amd64.Po ./arch/.deps/amd64.o.Po
  

On 2017-09-20 10:02, Yao Qi wrote:
>>> @@ -2941,9 +2949,9 @@ ifeq ($(DEPMODE),depmode=gcc3)
>>>  # into place if the compile succeeds.  We need this because gcc does
>>>  # not atomically write the dependency output file.
>>>  override COMPILE.post = -c -o $@ -MT $@ -MMD -MP \
>>> -	-MF $(DEPDIR)/$(basename $(@F)).Tpo
>>> -override POSTCOMPILE = @mv $(DEPDIR)/$(basename $(@F)).Tpo \
>>> -	$(DEPDIR)/$(basename $(@F)).Po
>>> +	-MF $(@D)/$(DEPDIR)/$(@F).Tpo
>>> +override POSTCOMPILE = @mv $(@D)/$(DEPDIR)/$(@F).Tpo \
>>> +	$(@D)/$(DEPDIR)/$(@F).Po
>>>  else
>>>  override COMPILE.pre = source='$<' object='$@' libtool=no \
>>>  	DEPDIR=$(DEPDIR) $(DEPMODE) $(depcomp) $(CC)
>> 
>> I have never tested it, but I assume the "depcomp" mode of dependency
>> management will have to be updated too.
> 
> I don't understand this comment.  The only change in on dependency
> tracking is that .Po file is moved to a new place (.deps/amd64.Po ->
> ./arch/.deps/amd64.o.Po).  The file contents don't change.
> 
> $ diff -u .deps/amd64.Po ./arch/.deps/amd64.o.Po
> --- .deps/amd64.Po	2017-09-20 07:57:04.903381133 +0000
> +++ ./arch/.deps/amd64.o.Po	2017-09-20 07:40:35.995718460 +0000
> @@ -1,4 +1,4 @@
> -amd64.o: ../../binutils-gdb/gdb/arch/amd64.c \
> +arch/amd64.o: ../../binutils-gdb/gdb/arch/amd64.c \
>   ../../binutils-gdb/gdb/arch/amd64.h 
> ../../binutils-gdb/gdb/arch/tdesc.h \
>   build-gnulib/import/stdint.h 
> ../../binutils-gdb/gdb/common/x86-xstate.h \
>   build-gnulib/import/stdlib.h \

I was wondering if this line needed changing

override COMPILE.pre = source='$<' object='$@' libtool=no \
	DEPDIR=$(DEPDIR) $(DEPMODE) $(depcomp) $(CC)

In particular, is DEPDIR treated as relative to the created object file 
or relative to the current working directory by depcomp.  I honestly 
don't even know when this actually used.

Simon
  

Simon Marchi <simon.marchi@polymtl.ca> writes:

> I was wondering if this line needed changing
>
> override COMPILE.pre = source='$<' object='$@' libtool=no \
> 	DEPDIR=$(DEPDIR) $(DEPMODE) $(depcomp) $(CC)
>
> In particular, is DEPDIR treated as relative to the created object
> file or relative to the current working directory by depcomp.  I
> honestly don't even know when this actually used.

depcomp has already taken care of it,

# Dependencies for sub/bar.o or sub/bar.obj go into sub/.deps/bar.Po.

I hack Makefile, to set "depmode=gcc",

# Dependency tracking information.
DEPMODE = depmode=gcc

and "make arch/amd64.o",

source='../../binutils-gdb/gdb/arch/amd64.c' object='arch/amd64.o' libtool=no DEPDIR=.deps depmode=gcc /bin/bash ../../binutils-gdb/gdb/../depcomp g++ -x c++ -std=gnu++11 -g -O2   -I. -I../../binutils-gdb/gdb -I../../binutils-gdb/gdb/common -I../../binutils-gdb/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../binutils-gdb/gdb/../include/opcode -I../../binutils-gdb/gdb/../opcodes/.. -I../../binutils-gdb/gdb/../readline/.. -I../../binutils-gdb/gdb/../zlib -I../bfd -I../../binutils-gdb/gdb/../bfd -I../../binutils-gdb/gdb/../include -I../libdecnumber -I../../binutils-gdb/gdb/../libdecnumber  -I../../binutils-gdb/gdb/gnulib/import -Ibuild-gnulib/import   -DTUI=1   -pthread -I/usr/include/guile/2.0 -I/usr/include/python2.7 -I/usr/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wformat-nonliteral -Werror -c -o arch/amd64.o ../../binutils-gdb/gdb/arch/amd64.c

and the dependency file is generated in arch/.deps/amd64.Po, which looks
right to me.