[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-recursive make & maintenance issue

From: Bob Friesenhahn
Subject: Re: Non-recursive make & maintenance issue
Date: Thu, 27 Nov 2003 11:29:38 -0600 (CST)

On Thu, 27 Nov 2003, Jirka Hanika wrote:

> > In other words, dealing with junk like
> >
> > apps_build_postgres_src_build_postgres_SOURCES
> >
> > is very tiring and failure prone.  Is there a reason why it can't
> > simply be
> >
> > apps/build-postgres/src/build-postgres_SOURCES ?
> Speaking as a random user, this would only be a win (to me) if the translation
> could also be significantly messified to keep your target above distinct from,
> say,
> apps/build/postgres-src-build/postgres_SOURCES
> or if this kind of conflict would be at the very least well diagnosed
> and warned about.

Right.  Since there is only one translation available, it doesn't
matter if the translation was done manually or automatically.
Automake's naming scheme requires the user's directory and file names
to be non-ambiguous after translation.

> But people have to interface automake-generated code with user stuff, and
> this is usually done through variables.  I expect a big problem here.

It is not a problem as long as Automake provides sufficient
automatic translation capabilities.  There just needs to be a standard
way to create definitions and refer to existing definitions, including
those that Automake generates for its use.

In order to avoid confusion, Automake could adopt a GNU-make function
style syntax which indicates where translations are required.

For example:

  $(xlate foo/bar++)_SOURCES

would be automatically translated by Automake to


and substitution of existing Makefile defines (but not defines based
on autoconf substituted values) should also work so the following
should produce the same result:

  $(xlate $(FOO_BAR))_SOURCES

This would be extremely useful since it would allow a package's
directory organization to be re-arranged without excruciating pain.

Bob Friesenhahn

reply via email to

[Prev in Thread] Current Thread [Next in Thread]