On Sun, 30 Nov 2003, Alexandre Duret-Lutz wrote: > >>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> 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.
Makefile.am is *not* a Makefile. It is input to a tool which processes it into a Makefile. I see no reason why Makefile.am can not incorporate features and syntax which diverge from 'make' since the tool (Automake) transforms this into strict make syntax. If a Makefile.am 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 Makefile.am in Makefile mode. 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 Makefile.in files. Bob ====================================== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen