Yes I think I mentioned earlier that I have it hosted at 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

On Tue, Feb 20, 2018 at 11:28 AM, Robert Dailey
<> wrote:
> On Thu, Jan 25, 2018 at 6:21 PM, Isaac Hier <> 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.

Reply via email to