Re: [RFC PATCH 0/1] Implement CMake build

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> Isaac Hier <isaachier@xxxxxxxxx> 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux