Re: easier nonrecursive makefiles

[Bob Friesenhahn]

On Mon, 2 Aug 2010, Bernd Jendrissek wrote:
> What about taking a cue from nobase_FOOS and having
>
> prefixed_nobase1_dist_SOURCES =
>  perl/Foo/Bar.pm \
>  perl/Foo/Baz.pm
>
> I'm deliberately conflating another issue: the all-or-nothing nature
> of nobase_FOOS.  In some source trees, it forces you to have a
> (hopefully small number of) recursive sub-Makefile.am.  The "nobase1"
> here would tell automake, "strip 1, but no other, pathname
> components".

It seems likely that you are talking about something else.  In the 
typical non-recursive build for a large project, it is necessary to 
specify the full "path" as part of all target name variables.  This 
becomes incredibly redundant and wasteful.  It makes non-recursive 
builds more challenging than similar recursive builds, when they do 
not need to be.  A common way to make maintenance of a large project 
easier is to put an Automake include file in each directory where one 
or more components are built.  Unfortunately, because these include 
files are currently absorbed verbatim, the include files need to know 
their location in the tree and include huge amounts of wasteful 
redundancy.  It would be quite useful if this makefile include had a 
way to refer to its own relative location both in raw form, and in the 
underscore-substituted form necessary to construct target variable 
names.  Automake could arrange to expand these substititions before 
evaluating any other Automake syntax.

For example, this:

# PCL coder module
bar_coders_pcl_la_SOURCES      = bar/coders/pcl.c
bar_coders_pcl_la_CPPFLAGS     = $(MODULE_EXTRA_CPPFLAGS)
bar_coders_pcl_la_LDFLAGS      = $(MODULECOMMONFLAGS)
bar_coders_pcl_la_LIBADD       = $(LIBMAGICK)

could become this:

# PCL coder module
%tldir%_pcl_la_SOURCES      = %ldir%/pcl.c
%tldir%_pcl_la_CPPFLAGS     = $(MODULE_EXTRA_CPPFLAGS)
%tldir%_pcl_la_LDFLAGS      = $(MODULECOMMONFLAGS)
%tldir%_pcl_la_LIBADD       = $(LIBMAGICK)

and then the entire source code comprising this build unit can easily 
be moved anywhere without needing to edit its specific Automake 
include file.  Since substitutions are then already done on the target 
names, there is the additional possibility of supporting natural POSIX 
path syntax (with forward slashes and dots) rather than the current 
stunted underscore syntax.  Natural paths make everything much easier 
to maintain.  The current stunted syntax only exists because it was 
easier for a developer back in the early days of Automake development 
to require 'make' syntax. Improved substitution syntax is left to the 
Automake designer.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/