Re: magic variables for included fragments

[Ralf Wildenhues]

Hi Akim,

* Akim Demaille wrote on Wed, Dec 03, 2008 at 02:58:22PM CET:
>  > * Ralf Wildenhues wrote on Sun, Oct 12, 2008 at 10:46:06PM CEST:
> >>> "RW" == Ralf Wildenhues <address@hidden> writes:

> Sorry I did not answer before.

No problem of course.

In the meantime I did come up with some patch for "fixed"
  include fragment.mk

that does sane recursive inclusion, but with backward compatibility
warnings, but said patch still has a bug.  I hope to be able to fix
it soon.

> In other projects I'm involved in we store in candidates/ branches
> that contain patches under discussion.  That makes it easier to try,
> experiment etc.
> 
> Could you please push this somewhere?  Thanks!

Yes, of course.  I will try to clean all this up and push it, hopefully
sometime this weekend.

>  > @@ -9151,6 +9169,70 @@ condition applies to the entire contents of that 
> fragment.
>  >  Makefile fragments included this way are always distributed because
>  >  they are needed to rebuild @file{Makefile.in}.
>  
>  > address@hidden $(AM_SUBDIR)
>  > address@hidden $(AM_PREFIX)
>  > address@hidden $(AM_CANON)
>  > address@hidden $(AM_REVERSE)
> 
> This is really excellent news, it will vastly simplify some Makefiles.
> It will also solve a problem I have found several times: if you share
> some directories in different projects (typically using svn externals
> or git sub modules), then it is basically impossible to put them at
> different places in the packages: they should always be at a fixed
> path from the top of the package.

Indeed.

> Otherwise too many things go wrong
> (especially the creation of .deps btw: automake does garbage if you
> include a local.mk which defines foo_SOURCES = $(prefix)/foo.cc: it
> creates '$(prefix)/.deps', and I really mean single quotes: the very
> string '$(prefix)' not interpolated (which it can't, of course)).

Yep.  :-/

A while ago (I'm sure it's been more than a couple of years now),
ventured at changing depout.m4 to lift this limitation.  I did have
something working back then, but it required invoking `make' at
config.status time.  I dropped this idea as being unsuitable in the
presence of bugs (e.g., if `make' reinvokes configure, then there
can be an endless loop).  Maybe I should go back and look again,
for example writing out a separate makefile could help...

> I confess that I like that facets of a single thing keep a common root
> in the names: AM_SUB_REL, AM_SUB_PREFIX, AM_SUB_CANON, AM_SUB_REV or
> something.  But of course concision does matter.

I agree with you on both accounts.  I am torn between these choices as
well.  If somebody has better ideas, they are welcome!

Cheers,
Ralf