Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Cc: "Peter Eriksen" <s022018@student.dtu.dk>
Subject: Re: [PATCH] Clean up the SunOS Makefile rule
Date: Wed, 02 Nov 2005 12:56:12 -0800	[thread overview]
Message-ID: <7voe52py4z.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20051102192730.GA17706@ebar091.ebar.dtu.dk> (Peter Eriksen's message of "Wed, 2 Nov 2005 20:27:31 +0100")

"Peter Eriksen" <s022018@student.dtu.dk> writes:

> Don't set a non-standard CURLDIR as default, and fix an error
> in Solaris 10 by setting NEEDS_LIBICONV.

Just to make it clear to everybody, these platform defines are
just to give default that is intended to help majority of the
users.  You do not have to cover everybody on that platform.
Giving *one* default CURLDIR, as long as it helps major portion
of the user base, would be helpful.  In other words, it is OK as
long as the user can say:

	solaris$ gmake CURLDIR=/I/have/my/curl/here

to override what you chose, and /opt/sfw/ is where *many* (if
not most) of the Solaris installations have curl.  I do not have
access to many different flavours of Solaris boxes, but one
machine I have at work (5.9) seems to have it installed there.

Could Solaris users on the list help us out, as Peter asks?  How
many of you have curl in /opt/sfw?  How many others have curl in
somewhere else and think that somewhere else would be more
appropriate default?  If this user poll results in either a
default location better than /opt/sfw, or diverse locations with
no clear majority, then it would make sense to remove the
current default, but otherwise I would say we do not need to
drop it.

People who built curl library and installed at random places
themselves do not count -- they know what they are doing and are
perfectly capable of overriding whatever we say in our Makefile
from the comand line.

Although I think always requiring LIBICONV is OK there, and it
probably is needed on *all* Solaris boxes, but in principle,
NEEDS_LIBICONV is similar.  If the user cannot say:

	solaris$ gmake NEEDS_LIBICONV= ;# No thanks, on my Solaris

to disable -liconv, and if some Solaris installations do not
want -liconv, then that is a problem.  But GNU make seems to do
the right thing; ifdef NEEDS_LIBICONV seems to evaluate to false
if your user overrides it to be empty from the command line.

      parent reply	other threads:[~2005-11-02 20:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-02 19:27 [PATCH] Clean up the SunOS Makefile rule Peter Eriksen
2005-11-02 19:49 ` Peter Eriksen
2005-11-02 20:56 ` 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=7voe52py4z.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=s022018@student.dtu.dk \
    /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