🚀 go-pugleaf

Following are two proposals for extensions to GNU-make. I don't know how one
usually get things added to GNU-make so I thought I would post to this group
and solicit comments. Both proposals are related but are not alternatives as
both could be implemented.

We have version 3.59, I could not however find anything in the documentation or
src to suggest that I can do this at the moment. If it can actually be done I
would like to hear how.

AIM:

At the moment, macros defined in the Makefile are converted to environment
variables which are inherited by commands run as part of a rule. These
macros are not expanded. For example:

  ONE = 1
  TWO = $(TWO)
  THREE = $@

  test:
	  env

Here the macros when placed in the environment become:

  ONE = 1
  TWO = $(ONE)
  THREE = $@

The aim of the proposed extensions is to enable the user to force certain
macros to be expanded when placed in the environment of commands run as part of
a rule. For example the above would result in the macros being expanded to:

  ONE = 1
  TWO = 1
  THREE = test

PRECEDENT:

This idea is not new and is possible using the make provided with Sun OS. For
example:

  test := THREE = $@

  test:
	  env

Note that Sun uses ':=' differently to GNU-make. In Sun make it is used to
specify a macro for a particular target only. A macro specified in this way is
expanded and placed in the environment of commands run as part of the rule.
The expansion of the macro is performed after special macros such as '$@' and
'$?' are defined corresponding to the target being executed.

PROPOSAL 1:

This is the simpler of the two proposals and would require only small to
moderate code additions. (Looking at the code of GNU-make I feel that even I
would be able to implement this and would even be prepared to do so)

It is proposed that a new special target along the lines of '.PHONY' be added.
For example:

  .EXPAND : ONE TWO THREE

All macros which are listed as a dependency of '.EXPAND' would be expanded
before being placed into the environment for commands run as part of a rule.
The expansion would occur after '$@', '$?' etc. had been defined
corresponding to the rule being executed. The macros would be expanded when
any rule is being executed. The example:

  .EXPAND : ONE TWO THREE

  ONE = 1
  TWO = $(ONE)
  THREE = $@
  FOUR = $(ONE)

  test:
	  env

would result in the environment variables:

  ONE = 1
  TWO = 1
  THREE = test
  FOUR = $(ONE)

being inherited by the environment.

I think this should also work when the GNU-make ':=' type of macro
definition is used, however I am not totally sure. The reason I am unsure is
because the macro would actually be getting expanded twice. I couldn't however
think of a case where it would cause a problem.

  .EXPAND : ONE TWO THREE

  ONE := 1
  TWO := $(ONE)
  THREE := $@
  FOUR := $(ONE)

  test:
	  env

PROPOSAL 2:

This second proposal would involve more work than the first. (I don't know
enough at the moment about the structure of the GNU-make code and so doubt that
I would be do this without some help)

It is proposed here to implement a feature comparable to the Sun make feature
described in 'PRECEDENCE' above. Namely to allow macros to be defined or
redefined for a particular target.

Since GNU-make already uses the ':=' notation which Sun make uses, an
alternative syntax would be required. The remaining sytnax would be the same.
For example:

  test :+ THREE = $@

Note that ':+' is used here, however an alternative could be used, eg. ':-'.
Also note that it may not make sense to allow:

  test :+ THREE := $@

As far as I can tell it could not be made to make things happen any
differently.

It is preferable that this proposal be implemented in conjunction with the
previous proposal. This would mean that by default the above would result in
an environment variable of

  THREE = $@

being created. However if

  .EXPAND : THREE

were defined then the result would be

  THREE = test

EXAMPLES:

My reason for putting forward these proposals is that I need to export
environment variables to commands run as part of a rule. The values of these
variables are dependent on the target, eg. '$@'.

A small example of what I am trying to do follows. (It is actually much more
complicated than this as we have structured things so that one doesn't need
to write Makefiles, default rules and macros just look at what is in the
directory and work out what should go into a library, what are executables,
etc)

  .EXPAND : SUNPRO_DEPENDENCIES

  SUNPRO_DEPENDENCIES = "$@..d $@"

  objects = foo.o foobar.o

  lib : $(objects)

  depfiles := $(wildcard *..d)

  ifneq ($(depfiles),$(empty))
  include $(depfiles)
  endif

The variable SUNPRO_DEPENDENCIES is understood by compilers found on Sun
workstations. The result of defining the variable is the creation of a file
which contains the dependencies of the target. These dependencies are generated
by all stages of the compilation process, eg. cpp/ccom/ld. The next time
GNU-make is run it will include the dependency information generated during the
previous compile.

The result of this simple Makefile script is that dependencies are
automatically generated and are always kept up to date. It is not necessary to
have a 'depend' target in the Makefile. If you like, this scheme is a poor
mans version of the 'KEEP_STATE' feature of Sun's make. Because GNU-make is
much more powerful in terms of what it can do, the overall result is better
than can be achieved with just Sun's make. This also allows GNU-make to be used
under Sun's NSE.

ALTERNATIVES:

Some will probably say that I can achieve the same result by having the
following:

%.o : %.c
	SUNPROD_DEPENDENCIES="$@..d $@" $(CC) -c $(CFLAGS) $?

This is true, but we do not wish to do this as it means that we have to
redefine a large number of the default rules. We actually already use this
scheme with a different make program which we use at the moment. We are
finding this unmanageable as users have to know about such things when
rewriting rules. Thus I propose the above as a way of achieving the same
results but without having to touch the default rules.



So, does anyone have any comments/suggestions.

--
Graham Dumpleton (grahamd@otc.otca.oz.au)