Fwd: Subpackage distclean removed parent package dep files

[BVK Chaitanya]

My below message got bounced -- due to attachement size limitations, I guess.


---------- Forwarded message ----------
From: BVK Chaitanya <address@hidden>
Date: Thu, Feb 18, 2010 at 2:00 PM
Subject: Re: Subpackage distclean removed parent package dep files
To: BVK Chaitanya <address@hidden>, address@hidden


I am able to "fix" this issue, by doing AC_SUBST(DEPDIR, [.deps2]) in
top-level configure.ac file.  Unfortunately, DEPDIR is not an automake
public API variable :-(


On Thu, Feb 18, 2010 at 1:24 AM, Ralf Wildenhues <address@hidden> wrote:
> Hello,
>
> * BVK Chaitanya wrote on Tue, Feb 16, 2010 at 07:02:11PM CET:
>> 1.  Enabling subdir-objects option creates .Po files in ".deps"
>> directories in each _SOURCE file's directories.
>
> Not each _SOURCE file's, but in the same directory in which the object
> will be put.  Which is the current builddir concatenated with the
> dirname of each source file.

Yes.  This is what I wanted to say.


> Does your setup actually build object files from the different packages
> into the same subdirectory?  Maybe even same object files?  That would
> sound dangerous to me.

Yes.  subdir-objects option seems to rename objects as
program-source.o, so they are two different object files (unless
program name is same, which is not the case anyway).

>
> Such things can often be avoided by rearranging the subdir structure a
> bit.

I suspect its not possible, because we don't want two copies of same
source file in the tree.  Since there is only one copy, its .o files
would end up in same subdir.  Only other mechanism is to have a lib.a
built, which is again not an option for my usecase, because I want to
use that source in two programs built by two (cross) compilers (one
lib.a wont do).

>> In a nested packages configuration, this can cause top-level packages'
>> _SOURCE and nested packages' _SOURCE to share same .deps directory
>> (specifically, if any source file is shared between both packages.)
>
> Typically, that is a bad idea, esp. if the packages' rules for building
> the object files get out of sync you have an implied race (a `cd subdir
> && make' will generate a different object from a plain make).

But I _want_ the rules to be different because, one program needs to
be compiled with HOSTCC and another with TARGETCC (think -m32/-m64
flags case).

Attached is a small testcase to reproduce this make distclean failure.
Its basically has nested hello world packages, where hello.c is shared
by both packages' Makefile.am. Relevant automake parts are:

=== testcase/Makefile.am

AUTOMAKE_OPTIONS = subdir-objects

SUBDIRS = subpackage

bin_PROGRAMS = main-tool
main_tool_SOURCES = main-tool.c subpackage/hello.c
main_tool_CPPFLAGS = -I$(top_srcdir)/subpackage

=== testcase/subpackage/Makefile.am

AUTOMAKE_OPTIONS = subdir-objects

EXTRA_DIST = hello.h

bin_PROGRAMS = sub-tool
sub_tool_SOURCES = sub-tool.c hello.c


Note that subpackage in SUBDIRS is a package with its own configure.ac
different from top-level configure.ac.


thanks,
--
bvk.chaitanya



-- 
bvk.chaitanya