autoconf-generated configure scripts substitute strings like @var@ in files like for the value of output variables set in the configure script. Most of the time, these will only be used in lines like var = @var@ in Makefile.in. The Makefile.in may have many of these lines. In fact, automake scans configure.ac for use of the AC_SUBST macro and automatically adds such lines to the generated Makefile.in. It can be confusing to try to understand what it means for variables to copied from one level of the build system to another. If a user writes Makefile.in by hand, they will have to write out all these lines manually. Also, it's hard to read Makefile.in's because of such lines. My suggestion would provide a simpler way which would work for most use cases. It would be to generate a file (called, say, "config.mk") which contained all these assignments automatically. I.e., config.mk would contain lines like CC = cc CXX = g++ and so on. Then in the Makefile, have a line "include config.mk". The output variables would be referred to in the Makefile as ordinary environment variable (e.g. $(CC)). This could be done with a macro like AC_CONFIG_INCLUDE(config.mk) in configure.ac. As well as being simpler (only having a Makefile instead of a Makefile and Makefile.in, and only having one type of variable instead of two (@var@ and $(var)), this would let the user browse through config.mk to see exactly what configure decided. At the moment, you would have to read config.status to do this, which is not easy. It may be advisable to also produce a config.mk.in file showing what variables are set. Then a user on a system where configure doesn't work would know what they had to set manually. (This is the same rationale for having a config.h.in.) There is a possible problem with the user running make before they run configure. In a lot of cases, the user doesn't care about the difference between make and configure, and wants to use the default configure options. Then a default config.mk could be included with a a rule to rebuilding itself by running configure. (GNU make would then read the produced config.mk in again.) Alternatively, the program developer could decide for make to spit out a message saying "Please run configure first." if they want to make running configure manually compulsory. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
