All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elia Pinto <gitter.spiros@gmail.com>
Cc: git@vger.kernel.org, stefano.lattarini@gmail.com
Subject: Re: [PATCH] configure.ac: move the private git m4 macro to a dedicated directory
Date: Fri, 09 Aug 2013 09:51:19 -0700	[thread overview]
Message-ID: <7v61ve7qpk.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1376059045-14866-1-git-send-email-gitter.spiros@gmail.com> (Elia Pinto's message of "Fri, 9 Aug 2013 07:37:25 -0700")

Elia Pinto <gitter.spiros@gmail.com> writes:

> Git use, as many project that use autoconf, private m4 macros.
>
> When not using automake, and just relying on autoconf, the macro
> files are not picked up by default.
>
> A possibility, as git do today, is to put the private m4 macro
> in the configure.ac file, so they will copied over  the final configure
> when calling autoreconf(that call also autocon). But this makes configure.ac difficult
> to read and maintain, especially if you want to introduce new macros later.
>
> Starting from version 2.58, autoconf provide the macro AC_CONFIG_MACRO_DIR
> to declare where additional macro files are to be put and found.
> The argument passed to this macro is commonly m4.
>
> This macro, for the longest time, has been used only by libtool
> starting from version 2.0, to identify where to copy its own macro files
> when using libtoolize --copy.
>
> Starting from version 1.13, automake augments autoconf with a macro
> called AC_CONFIG_MACRO_DIRS, that provides a space-separated list
> of directories to use for looking up m4 files.
> The same macro will be available as part of autoconf 2.70,
> actually in development. Anyway also this version permit
> to use AC_CONFIG_MACRO_DIR and not need automake.
>
> Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>

That explains why you created a separate directory to for the new
file and why you needed to use AC_CONFIG_MACRO_DIR while doing so.

But in the above explanation, I fail to see the reason why we would
want to create that new file out of the existing file, only to
include it in the original file.

Why is it needed?  Why is it a good idea?

  reply	other threads:[~2013-08-09 16:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-09 14:37 [PATCH] configure.ac: move the private git m4 macro to a dedicated directory Elia Pinto
2013-08-09 16:51 ` Junio C Hamano [this message]
2013-08-09 17:52   ` Elia Pinto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v61ve7qpk.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitter.spiros@gmail.com \
    --cc=stefano.lattarini@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.