Re: [RFC] Replicate src dir in build dir

[Simon Marchi <simon dot marchi at polymtl dot ca>]

On 2017-09-19 16:42, Yao Qi wrote:
> Nowadays, GDB build tree is almost flat, but source tree isn't.  We
> have arch/ nat/ target/ common/ cli/ mi/ tui/ python/ guile/ 
> directories.
> We need to some rules in Makefile for source files in different source
> directories, like,
>
>  # Rules for compiling .c files in the various source subdirectories.
> %.o: ${srcdir}/arch/%.c
> 	$(COMPILE) $<
> 	$(POSTCOMPILE)
>
> %.o: ${srcdir}/nat/%.c
> 	$(COMPILE) $<
> 	$(POSTCOMPILE)
>
> so we should take care of some special case that files' base name is 
> the
> same, like,
>
>  # Specify an explicit rule for gdb/common/agent.c, to avoid a clash 
> with the
>  # object file generate by gdb/agent.c.
> common-agent.o: $(srcdir)/common/agent.c
> 	$(COMPILE) $(srcdir)/common/agent.c
> 	$(POSTCOMPILE)
>
> As we add more and more files in different directories, it becomes 
> tricky
> to name files, because we need take this into account.
>
> This patch takes the first step toward "Replicate src dir in build 
> dir",
> that is, we create arch/ directory in buildtree, and put amd64.o there
> as an example.  Dependency tracking is updated for files with directory
> name.  Currently, when we build amd64.o,
>
>   "-c -o amd64.o -MT amd64.o -MMD -MP -MF .deps/amd64.Tpo"
>
> with this patch applied, it becomes,
>
>   "-c -o arch/amd64.o -MT arch/amd64.o -MMD -MP -MF 
> arch/.deps/amd64.o.Tpo"
>
> "make clean" removes the object files, and "make distclean" removes 
> .deps
> additionally.  configure file create .deps directory in each of
> CONFIG_SRC_SUBDIR, and pass it to Makefile.in, so that "make clean" and
> "make distclean" can remove stuffs there.
>
> If people agree with this change, I'll add more directories to
> CONFIG_SRC_SUBDIR.  I want to do the same to GDBserver, but I haven't
> looked at GDBserver configure/Makefile yet.

Hi Yao,

I like the idea.  I tried to do that when I cleaned up the Makefiles 
some time ago, but since it wasn't obvious I let it go.

>  # This used to depend on c-exp.c m2-exp.c TAGS
>  # I believe this is wrong; the makefile standards for distclean just
> @@ -2317,6 +2322,9 @@ distclean: clean
>  	rm -f config.log config.cache
>  	rm -f Makefile
>  	rm -rf $(DEPDIR)
> +	@for i in $(CONFIG_SRC_SUBDIR); do \
> +		rm -rf $$i/$(DEPDIR); \
> +	done

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.

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

Thanks!

Simon