From: Junio C Hamano <junkio@cox.net>
To: Dennis Stosberg <dennis@stosberg.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/4] More tests for hand-written configure (resend)
Date: Fri, 07 Jul 2006 12:40:46 -0700 [thread overview]
Message-ID: <7vhd1tw6dd.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: 20060707162513.25746.57374.stgit@leonov.stosberg.net
Dennis Stosberg <dennis@stosberg.net> writes:
> I noticed that the autoconf-based solution has replaced Pasky's
> scripts in the pu branch. Has a final decision been made?
My preference has been to see both sides battle it out without
forcing me to decide, but...
> I must admit that I'm less convinced today that a hand-written
> configuration script is better than I was yesterday when I started
> to write the tests.
... I started to share the same feeling after Pavel Roskin made
a good point in "git on HP-UX" thread,
http://thread.gmane.org/gmane.comp.version-control.git/23380/focus=23393
and then after seeing the messages in response to your patch
that used `which` from yesterday.
Shell scripts generated by autoconf are almost unreadable, but
the way how they detect features have been polished in the field
for portability for a long time, and there is no point for us to
spend time reinventing the wheel. The configure.ac files are
often quite readable even when generated configure scripts are
not.
So, I would not veto the use of autoconf, as long as configure
stays as an _optional_ mechanism to manage config.mak.gen that
is used by the main Makefile. The users for whom the configure
script breaks for whatever reason can work it around by simply
not using it, instead of having to debug either the unreadable
configure or having to install autoconf and debug configure.ac
just to build git.
The _optional_ is really the key word here. So "make clean" to
clean autoconf intermediate files is good, "make realclean" to
remove "configure" script generated from "configure.ac" is also
good, but if "make rpm" by default runs "configure", then that
is BAD and I would be very unhappy.
I could probably live with "make rpm-using-configure", though.
prev parent reply other threads:[~2006-07-07 19:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-07 16:25 [PATCH 0/4] More tests for hand-written configure (resend) Dennis Stosberg
2006-07-07 16:26 ` [PATCH 1/4] configure: Add test for Perl Dennis Stosberg
2006-07-07 16:26 ` [PATCH 2/4] configure: Add test for Python Dennis Stosberg
2006-07-07 16:26 ` [PATCH 3/4] configure: Try to figure out compiler options Dennis Stosberg
2006-07-07 16:26 ` [PATCH 4/4] configure: Fixes for Solaris Dennis Stosberg
2006-07-07 19:40 ` Junio C Hamano [this message]
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=7vhd1tw6dd.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=dennis@stosberg.net \
--cc=git@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox