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.