Re: distclean-recursive broken?

[Alexandre Duret-Lutz]

On Mon, Feb 16, 2004 at 02:04:59PM +0100, Ralf Corsepius wrote:
>
> > is a legitimate user sequence. `make dist' should distribute all
> > directories (all those listed in DIST_SUBDIRS, not only the
> > subset to built with `make all' which is listed in SUBDIRS),
> Please read what you wrote ;)

Yes, please read what I wrote, it really looks right :)

> ...'make dist' all those ... in DIST_SUBDIRS ...
>
> => "make dist" make should recurse into DIST_SUBDIRS.

Yes!  Yes!

> ATM, however:
> - "make dist" recurses into SUBDIRS!!!

`make dist' recurses into $(SUBDIRS) only when $(DIST_SUBDIRS) has not
been defined by the user, probably you have been mistaken by this.  In
our case $(DIST_SUBDIRS) is defined so it recurses into
$(DIST_SUBDIRS).

> - "make distclean-recursive" recurses into DIST_SUBDIRS.

Yes.  It recurse in the same directories as `make dist'.

> > To remove the Makefile that each DIST_SUBDIRS directory must have.
> Where do you expect these Makefiles to come from?

They fall from the sky when ./configure runs :)

> With autoconf/automake based configurations, these Makefile's stem from
> preceding configure runs:
>
> ** configure ... recurses into SUBDIRS **

Come on... SUBDIRS is a Makefile variable, configure knows nothing
about it.   ./configure recurses where you told it to recurse.
It's your decision.

The full SUBDIRS/DIST_SUBDIRS architecture assumes that a Makefile
have been created in all directories listed in DIST_SUBDIRS.  So *you*
should ensure that ./configure recurses into these directories.

This is what the manual means when it says to create Makefiles
unconditionnally and not to try doing otherwise.  Conditional SUBDIRS
just helps to omit directory from the build proper (i.e., make all)
not from configuration or distribution.

> > If there is a directory `make distclean' must not recurse into
> > because there is no Makefile, then `make dist' cannot recurse
> > into this directory either, hence this directory must not be
> > listed in DIST_SUBDIRS.
> In this case, there is not any need to have it in SUBDIRS.

Yes, exactly!  Now at least we have reached agreement on one point:
$(SUBDIRS) must be a subset of $(DIST_SUBDIRS).

> So you are proposing to set
>
> SUBDIRS = @subdirs@
> DIST_SUBDIRS = @subdirs@
>
> .. and yes, this seems to work for me.
>
> This is not an actual surprize to me, because this sets
> SUBDIRS == DIST_SUBDIRS.
>
> >   Since they have a Makefile `make
> > distclean' must also recurse into them to remove it.
> Wrong.
>
> configure recurses into SUBDIRS.

I guess all your problem comes from this idea.  If you now consider
that ./configure must recurse into DIST_SUBDIRS (and in your case
setting DIST_SUBDIRS = $(SUBDIRS) is a way to satisfy this) it
probably makes more sense.

> > DIST_SUBDIRS is tied to `make dist', not to AC_CONFIG_SUBDIRS.
> Then the recursive configuration step which is part of "make dist"
> should recurse into DIST_SUBDIRS.

Yes.  This is what is expected to happen.  The testcase I cited
earlier checks this.

> I have config-subdirs, configure in can only be run conditionally.

Yes.  We do not have proper support for conditional AC_CONFIG_SUBDIRS
presently (as you've have discovered).  Hacks are possible, but:
> > I do not recommend [these hacks] because it's then easy to make
> > incomplete distributions by mistake.
> You should consider to change this attitude :(
>
> There are occasions where conditional SUBDIRS are inevitable,

Sure.  But these are reasons to add support for conditional
AC_CONFIG_SUBDIRS.  I'd prefer to do this rather than recommanding
ugly hacks which are error-prone.

> 1. Some subdirs might be optional sub-packages. Presence of these
> sub-packages can be detected by higher level configure scripts, autoconf
> supports such conditionally presence of subdirs.

For this I presently recommand to configure the sub-package
unconditionally, list it in DIST_SUBDIRS, and conditionally omit it
from SUBDIRS.

In fact this is the example of the manual (if you replace
AC_CONFIG_FILES(opt/Makefile) by AC_CONFIG_SUBDIRS(opt)).

I agree this extra ./configure is a waste of time.  However it is
clean and safe.

> 2. Some subdirs/sub-packages might not be compilable on certain hosts.
> E.g. I have sub-packages, which can only be configured on certain
> architectures. Your perspective would require me to add
> AM_CONDITIONAL([VALIDARCH],[test "$host_cpu" = "supported_cpu"]) to
> those subpackages and to apply this conditional in all of these
> packages' Makefile.ams.

Yeah.  That's a problem for which you presently need dirty hacks.

> 3. VPATH/multiple builds: The build-directory tree does not necessarily
> have to match with the source directory-tree.

I don't understand this one.

> Now combine all this and you have my actual situation.

Please accept my deepest condolences :(  It surely isn't fun.

> Frankly speaking, IMO, this paragraph is a masterpiece of "saying
> nothing with a lot of words". Instead of giving such prosaic
> explanation, it should be condensed to
> "cooking recipes".

Don't they come immediatly after?

> > Is it clearer now?
> No. IMO we are talking past each other.

I think we are getting somewhere, aren't we?

> To me, the essentials are:
> * Current automake does not support conditional subdirs.

It does not support *conditionally configured* subdirectories.

But it supports unconditionally configured subdirectories that are to
be built conditionally (SUBDIRS) and still be distributed
unconditionally (DIST_SUBDIRS).

> * There exists an inconsistency/bug in automake: configure/make recurses
> into SUBDIRS, "distclean-recursive" recurses into DIST_SUBDIRS.

>From my point of view the only problem is that you are taking SUBDIRS
and DIST_SUBDIRS for what they are not.  They are not here to solve
the conditional configuration problem, they just help with conditional
builds, assuming unconditional configurations.

> Even more condensed: DIST_SUBDIRS must be identical to SUBDIRS,
> anything else does not work.

If the only directories you want to build conditionally are
conditionally configured, this is true.  You may also omit
DIST_SUBDIRS entirely with similar effect.  (Automake considers
that DIST_SUBDIRS = $(SUBDIRS) when DIST_SUBDIRS is undefined.)

Recursively yours,