[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: Sun, 30 Nov 2003 12:06:25 -0600 (CST)

On Sun, 30 Nov 2003, Alexandre Duret-Lutz wrote:

> >>> "Bob" == Bob Friesenhahn <address@hidden> writes:
> [...]
>  Bob> In other words, dealing with junk like
>  Bob> apps_build_postgres_src_build_postgres_SOURCES
>  Bob> is very tiring and failure prone.  Is there a reason why it can't
>  Bob> simply be
>  Bob> apps/build-postgres/src/build-postgres_SOURCES ?
> Yes.  Makefile variable names can only consist of alphanumerics,
> underscores, and periods.  Use of any other character is not
> standard, and likely not portable.
> `/' is definitely not portable; for instance OSF1 Make has a
> special operator $(MACRO/left/right) that would conflict with
> such variable names. is *not* a Makefile.  It is input to a tool which
processes it into a Makefile.  I see no reason why can not
incorporate features and syntax which diverge from 'make' since the
tool (Automake) transforms this into strict make syntax.  If a identifier violates 'make' syntax, then it can simply be
transformed into an identifier which is compatible with 'make' syntax.
With a little care, emacs can still edit in Makefile

A legacy implementation simplification is causing non-recursive
Makefiles to be tremendously more difficult to develop and maintain
than need be.  Recursive makefiles only occassionally need
name-munging to comply with Automake syntax (if the author chose an
odd name for his library or program), but non-recursive makefiles need
this name-munging for each and every target definition since
subdirectory paths include '/'.

If Automake has a reliable way to tell when an identifier must be
munged, then there is no reason why it can't do this automatically
while it generates the files.

Bob Friesenhahn

reply via email to

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