patchautoconf: Use autoconf to write installation directories to config.mak

This is beginning of patch series introducing installation configuration using autoconf (and no other autotools) to git. The idea is to generate config.mak using ./configure (generated from configure.ac) from config.mak.in, so one can use autoconf as an _alternative_ to ordinary Makefile, and creating one's own config.mak.

This patch includes minimal configure.ac and config.mak.in, so one can set installation directories using ./configure script e.g. ./configure --prefix=/usr

Ignoring files generated by running autoconf and ./configure

Signed-off-by: Jakub Narebski <jnareb@gmail.com>

---

One of the ideas is to use in .spec RPM macro %configure which takes care of setting all installation directories correctly.

Thoughts?

 .gitignore    |    4 ++++
 config.mak.in |   12 ++++++++++++
 configure.ac  |   11 +++++++++++
 3 files changed, 27 insertions(+), 0 deletions(-)

Jakub Narebski wrote:

autoconf does to much things, even with that little configure.ac. (But I agree, it's much better than automake :-)

E.g.

	./configure --prefix=$HOME/usr --mandir=$HOME/usr/share/man

is supported by the configure script, but the manpages are installed in $HOME/usr/man all the same.

BTW: Even if I specify mandir=... in config.mak, it is not respected,
because only the toplevel Makefile includes config.mak.  (I didn't test
it, but I think I could export mandir in config.mak ...)

Best regards Uwe

./configure script checks now if the following libraries are present:
 * -lcrypto (checks for SHA1_Init, sets NO_OPENSSL=YesPlease if not found)
 * -lcurl   (checks for curl_easy_setopt, sets NO_CURL=YesPlease if not found)
 * -lexpat  (checks for XML_ParserCreate, sets NO_EXPAT=YesPlease if not found)

Appropriate lines in config.mak are generated using MY_APPEND_LINE macro by adding lines to temporary file config.mak.append

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---

Second patch in series introducing nonintrusive autoconf support to git build process.

I'm not that sure about -lcrypto equals openssl.

 configure.ac |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

./configure script checks now for existence of the following types
and structure members:
 * dirent.d_ino  in dirent.h (NO_D_INO_IN_DIRENT)
 * dirent.d_type in dirent.h (NO_D_TYPE_IN_DIRENT)
 * 'struct sockaddr_storage' in netinet/in.h (NO_SOCKADDR_STORAGE)

./configure script checks now for the following library functions:
 * strcasestr (NO_STRCASESTR)
 * strlcpy (NO_STRLCPY)
 * setenv (NO_SETENV)
in default C library and in libraries which have AC_CHECK_LIB done for
them (crypto, curl, expat).

NOTE: not all checks are implemented!

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---

This patch needs review by someone better versed in compiling git on different platforms, namely AC_CHECK_MEMBER and AC_CHECK_TYPE needs checking if all header files where git search for specified structure member or specified type.

I don't know (yet) how to implement checking for NEEDS_SSL_WITH_CRYPTO (probably also checlking for crypto library needs correction), NEEDS_LIBICONV, NEEDS_SOCKET, NO_IPV6, NO_ICONV, Python < 2.3 and Python == 2.3, if to check for NO_MMAP, and for NO_ACCURATE_DIFF.

This patch is to be considered preliminary!

 configure.ac |   28 ++++++++++++++++++++++++++--
 1 files changed, 26 insertions(+), 2 deletions(-)

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
 configure.ac |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

Makefiles in subdirectories now use existing value of INSTALL, bindir, mandir if it is set, allowing those to be set in main Makefile or in config.mak. Main Makefile exports variables which it sets.

Renames man1 and man7 variables to man1dir and man7dir, according to "Makefile Conventions: Variables for Installation Directories" in make.info of GNU Make. Renames bin to bindir (unused, perhaps to be removed).

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Part of autoconf series, but independent.

Should probably be split into two patches:
 * first with export + '?='
 * second renaming man1 and man7 to man1dir and man7dir

 Documentation/Makefile   |   14 +++++++-------
 Makefile                 |    2 ++
 contrib/emacs/Makefile   |    4 ++--
 contrib/git-svn/Makefile |    8 ++++----
 4 files changed, 15 insertions(+), 13 deletions(-)

This patch with the previous "[PATCH] Allow INSTALL, bindir, mandir to be set in main Makefile" patch allows ./configure script to set where manpages will be installed using --mandir=DIR (./configure defaults to PREFIX/man).

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---

Uwe Zeisberger wrote:

This patch and previous one adressess this.

 config.mak.in |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

configure.ac now uses variables to set input file (containing strings substituted by ./configure script), temporary file (for appending lines to output file) and output file (with the result configuration).

This is preparation to using other file than config.mak for output.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
 configure.ac |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

---
So now to actually use ./configure output you either have to add
  -include config.mak.auto
to Makefile before including config.mak, link config.mak.auto to config.mak, 
or rename (move) config.mak.auto to config.mak after done with ./configure

 configure.ac |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
 configure.ac |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Probably there is better way to do this.

 configure.ac |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Choose the name you are more comfortable with

 configure.ac |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

This reverts 6015ccba6c0439b0b615615aacefaf463c546ba4 commit.

To be replaced by better solution, idea by Andreas Ericsson --- Or just not apply [PATCH 10] (and this patch)

 configure.ac |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Andreas Ericsson wrote:

Done, with small changes.

Can anyone tell me if frep use is portable enough?

 configure.ac |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Jakub Narebski wrote:

Gah, should be of course

+grep -q -s -F -e "-include ${config_file}" config.mak || \
+            echo "-include ${config_file}" >> config.mak

Added --with-PACKAGE[=PATH] (where PATH is prefix for PACKAGE libraries and includes) and --without-PACKAGE (--with-PACKAGE=no) support for curl, openssl, expat to configure.ac

Signed-off-by: Jakub Narebski <jnareb@gmail.com>

---

I'm not autoconf/m4 expert: could anyone tell me how to uppercase PACKAGE name, so one could write MY_PARSE_WITH(openssl)?

How to add [=PATH] to --with-PACKAGE option description in a way which does not screw up AS_HELP_WITH calculations. I could use @<:@=PATH@:>@ which transforms to [=PATH], but AS_HELP_WITH counts number of characters in source I think.

 configure.ac |   34 ++++++++++++++++++++++++++++++++++
 1 files changed, 34 insertions(+), 0 deletions(-)

Hi Jakub,

On Fri, 2006-06-30 at 23:45 +0200, Jakub Narebski wrote:

I don't quite understand what you want, but you could check m4_toupper.

Try another pair of square brackets as quotes for literal contents. In this case, use [[=PATH]]

By the way, it's better to use a prefix other than MY. I thing GIT_PARSE_WITH would be great.

<posted & mailed>

Pavel Roskin wrote:

Thanks. It works great. GIT_PARSE_WITH is now:

AC_DEFUN([GIT_PARSE_WITH],
[[PACKAGE=m4_toupper($1); \
if test "$withval" = "no"; then \
    GIT_APPEND_LINE(NO_${PACKAGE}=YesPlease); \
  elif test "$withval" != "yes"; then \
    GIT_APPEND_LINE(${PACKAGE}DIR=$withval); \
  fi; \
]])# GIT_PARSE_WITH

I suspect that AS_HELP_WITH does some strange quoting, or stripping. Both [=PATH] and [[=PATH]] produces =PATH in ./configure --help output. When using @<:@=PATH@:>@ I get [=PATH], but the description of option begins line below.

Any ideas for name of MY_APPEND_LINE(LINE)/GIT_APPEND_LINE(LINE) macro, which as a result adds line to output (e.g. LINE = "NO_CURL=YesPlease")?

Thanks for all suggestions

Jakub Narebski wrote:

Of course to do anything for --with-expat=PATH case this patch needs the one that introduces EXPATDIR (there was such patch on the list, I'm not sure if it got accepted).

Jakub Narebski <jnareb@gmail.com> writes:

I'd like to take something like this, independently from "optionally managing config.mak with autoconf" series.

And I think it is probably a good idea to somehow keep people's configurations that have been overriding man1 and man7 if possible. Otherwise things would regress for them.

Junio C Hamano wrote:

Done. Resent as two patch "series", starting with
Message-Id: <200606292211.28352.jnareb@gmail.com>

Are you sure this should be named config.mak? From INSTALL:

So with another filename either include it
- before config.mak: the user may override ./configure options with
  config.mak
- after config.mak: ./configure overrides config.mak
At least do not overwrite config.mak if it exists.

Matthias Lederhofer wrote:

The idea was to use ./configure to _generate_ config.mak, which the user can then edit.

But perhaps using another filename for results of ./configure script (and including it in main Makefile) would be better idea.

But one might want to run ./configure with different options, to finally arrive at the set which is satisfactionary. So unless some magic to detect if config.mak was generated from ./configure script, or generated by user is used...

Jakub Narebski wrote:

This is bad, since it forces users to do one thing first and then do what they're used to. Better to have the script add

-include config.mak.autogen

LAST in config.mak, unless it's already in the file and generate config.mak.autogen with configure.

Since Make does things bottoms-up (much like swedish students and midsummer celebrators), the previous hand-edited defaults in config.mak will beat the ones in config.mak.autogen (a good thing).

grep -q autogen config.mak || \
	echo "-include config.mak.autogen" >> config.mak

I wouldn't want my long-standing, functioning config.mak overwritten, but I *might* be interested in trying some of the options provided by ./configure.

Andreas Ericsson wrote:

Thanks for the solution. Done in my latest patch.

Andreas Ericsson wrote:

That's not true, unless we use '?=' assignment in Makefile. And we _want_ to override defaults provided in main git Makefile, so in config.mak.autoconf, and probably in user's own config.mak we use '=' overriding assignment. So it would be better to just add "-include config.mak.autogen" to makefile before "-include config.mak", as in patch below.

Matthias Lederhofer <matled@gmx.net> writes:

Think of it as an incredibly smart editor that you can use to edit your config.mak. As far as I understand it, this is an "opt-in" way for you to manage config.mak without editing it yourself, so I do not have much objections to the series in principle.

I think it is fair to say that autoconf is not so bad compared to its worse friends, but I am biased -- I used to deal with autoconf quite a lot in old days (before there were automake nor libtool), and my own changes to autoconf might still be surviving in a few .m4 files but I doubt it it was so long ago.

Having said that, I am skeptical how well we can keep this contained only to config.mak and keep it "opt-in", so I am not enthused to have this series at the toplevel of the tree.

It would have been a bit easier to swallow if this whole machinery to build config.mk were somewhere under contrib/ (say in contrib/autoconf), with an instruction to make an "opt-in" symlink "ln -s contrib/autoconf/config.mk config.mk" for people who want to use it in the toplevel INSTALL file, perhaps.

The one that touches the Makefile to propagate some variables down to submakes is probably a desirable change but that is pretty much independent from the series.

Pavel Roskin wrote:

Sending reply to GMane newsgroup tied to mailing list, and via email 
to author, but _not_ via mail to mailing list would do that... 
especially if the author I'm replying to doesn't use newsgroup 
interface.
 

Well, [=PATH] or [[=PATH]] doesn't work even if GIT_APPEND_LINE is without double quotes. Besides, that doesn't matter because this is inside of AS_HELP_STRING macro. No combination of quoting (I think I tried all) works... I guess I would just not use AS_HELP_STRING, and format help message "by hand".

I'm following example set by main Makefile. That, and I tried to make configure.ac as simple as possible...

By the way, if you know autoconf well, perhaps you could tell me how to write tests for the following programs: ar, tar, rpmbuild, how to write test for Python version (or rather for WITH_OWN_SUBPROCESS_PY) and other test autoconf.ac lacks now (NEEDS_SSL_WITH_CRYPTO, NEEDS_LIBICONV, NEEDS_SOCKET, NO_MMAP, NO_IPV6, NO_ICONV, NO_ACCURATE_DIFF unless that was removed or changed name).

Hello, Jakub!

On Sat, 2006-07-01 at 19:55 +0200, Jakub Narebski wrote: 

Sorry, I misunderstood the problem. I think it's pure cosmetics. Please don't let it stop you.

Please don't wast time on such minor things. It's more important to get the functionality implemented.

Generally, see the Autoconf manual for the specific test first, then for more common test.

For ar, use AC_CHECK_TOOL to allow cross-compilation. For tar and rpmbiuld, use AC_CHECK_PROG. Python will have to run to find the version, I'm afraid, which would complicate cross builds. Fortunately, it's on the way out.

Tests for sockets are described in the Autoconf documentation. Other tests should probably be implemented as test programs unless they can be reduced to checking for a specific symbol in a specific library.

On 7/1/06, Petr Baudis <pasky@suse.cz> wrote:

Easiest way is to output ./configure result to e.g. configure.mak.autoconf, and include this file just before configure.mak in main Makefile.

Just as in patches (although you have to discard or revert two alternate mechanism patches)