Yes I think I mentioned earlier that I have it hosted at https://github.com/isaachier/git. I have been busy with a few things so have not continued much since I started this conversation, but it covers a large part of the Makefile if not all the significant portions. On Tue, Feb 20, 2018 at 11:28 AM, Robert Dailey <rcdailey.lists@xxxxxxxxx> wrote: > On Thu, Jan 25, 2018 at 6:21 PM, Isaac Hier <isaachier@xxxxxxxxx> wrote: >> Hi Jeff, >> >> I have been looking at the build generator, which looks promising, but >> I have one concern. Assuming I can generate a CMakeLists.txt that >> appropriately updates the library sources, etc. how do you suggest I >> handle new portability macros? For example, assume someone adds a >> macro HAVE_X to indicate the availability of some platform-specific >> function x. In the current Makefile, a comment would be added to the >> top indicating when HAVE_X or NO_X should be set, and that option >> would toggle the HAVE_X C macro. But CMake can test for the >> availability of x, which is one of the main motives for adding a CMake >> build. The current build generator uses the output of make, so all it >> would know is whether or not HAVE_X is defined on the platform that >> ran the Makefile, but not the entire list of platform that git >> supports. >> >> Bottom line: should I add the portability tests as they are now, >> without accounting for future portability macros? One good alternative >> might be to suggest the authors of new portability macros include a >> small sample C program to test it. That would allow me to easily patch >> the CMake tests whenever that came up. In a best case scenario, a >> practice could be established to write the test in a specific >> directory with a certain name so that I could automatically update the >> CMake tests from the build generator. > > Isaac, > > I'm very happy that you have started support for CMake. I have a lot > of experience with it. I'd love to help contribute. Do you have a fork > on github where this code is? I'd have to figure out how to apply a > patch from email, I haven't done it before. I think the goal should be > to replace the existing build system (this can be a transition that > happens slowly). I've been in situations where multiple build systems > are supported in parallel, worst case because of split personal > preferences on a project. That is more counterproductive than asking > the team to just compromise and take the initial hit on learning > curve. Ultimately that's up to the Git community, but that would be my > recommendation. But I think making CMake as complete as possible will > help build that confidence and trust. I can completely understand the > complexities and concerns they have.
