git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Isaac Hier <isaachier@gmail.com>, git@vger.kernel.org
Subject: Re: [RFC PATCH 0/1] Implement CMake build
Date: Wed, 24 Jan 2018 21:53:10 +0100	[thread overview]
Message-ID: <87a7x3kmh5.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqpo5zdrgm.fsf@gitster.mtv.corp.google.com>


On Wed, Jan 24 2018, Junio C. Hamano jotted:

> Isaac Hier <isaachier@gmail.com> writes:
>
>> I realize this is a huge patch, but does anyone have feedback for the
>> general idea?
>
> I personally am not interested, especially with the justification
> given in the cover letter.
>
> Perhaps the one in this patch may be "mostly complete", and I am
> sure you can make it "complete" against a frozen target, but it is
> unclear to me how you envision keeping the completeness up to date.
>
> Whenever a developer needs to introduce a new build knob, the
> support for it needs to be implemented in not just Makefile but now
> also in this other thing.  Unless there is an automated
> bi-directional gateway to allow those who have been writing and
> reading Makefile not to worry about those who wants to build with
> CMake, and vice versa, you are forcing everybody to do the same work
> twice, no?
>
> Choice of build procedure for a project is like choise of SCM to
> store its source file.  If the new system is 10x better to make it
> worthwhile to educate everybody to use it, switching to a new system
> and ditching the current one *is* a reasonable thing to propose and
> consider.
>
> But I do not think you are proposing to switch, and I do not think
> you are convincingly arguing that it is 10x better than the current
> one, either.

There's more than 400 lines of instructions at the top of our current
Makfile. Most of that is of the form "if your system has/doesn't have
so-and-so, define so-and-so".

For whatever reason we've decided not to make autoconf a hard
dependency. I don't know/remember what those reasons are, but if we
could get *some* build system that could use compilation results to
drive its build that would be worth it.

I don't know if cmake is that system, i.e. if we could waive a magic
wand and replace our current build system with it whether we'd still
need a fallback Makefile on some platforms. Is it as portable as GNU
autoconf & make? I don't know.

It would be very nice if git's build system wouldn't require patches
like my fb95e2e38d ("grep: un-break building with PCRE >= 8.32 without
--enable-jit", 2017-06-01), which is only needed because we don't have a
way to run a small C program to determine what the value of something
like NO_LIBPCRE1_JIT should be.

Well, we have it *optionally* with autoconf, but as long as it's
optional we don't save ourselves any time, and from packages I've seen
in the wild most people who build git don't use it, so it wouldn't save
them any time either.

  reply	other threads:[~2018-01-24 20:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23  0:16 [RFC PATCH 0/1] Implement CMake build Isaac Hier
2018-01-23  0:16 ` [RFC PATCH 1/1] " Isaac Hier
2018-01-24 13:45 ` [RFC PATCH 0/1] " Isaac Hier
2018-01-24 18:11   ` Jacob Keller
2018-01-24 18:47   ` Junio C Hamano
2018-01-24 20:53     ` Ævar Arnfjörð Bjarmason [this message]
2018-01-24 21:15   ` Stephan Beyer
2018-01-24 21:19     ` Isaac Hier
2018-01-24 22:02       ` Stephan Beyer
2018-01-25  2:16         ` Isaac Hier
2018-01-24 19:36 ` Jeff Hostetler
2018-01-24 19:59   ` Isaac Hier
2018-01-24 21:00     ` Jeff Hostetler
2018-01-24 21:17       ` Isaac Hier
2018-01-26  0:21       ` Isaac Hier
2018-01-26 17:34         ` Jeff Hostetler
2018-02-20 16:28         ` Robert Dailey
2018-02-23 18:48           ` Isaac Hier

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=87a7x3kmh5.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=isaachier@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).