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

From: Isaac Hier <isaachier@gmail.com>
Date: Jan 26, 2018, 00:21 UTC
Message-ID: <CAG6xkCa_nKtzhJJq=v7gazWe+8FnN3mz1vDftzZw2WUFqJ1bzw@mail.gmail.com>
In-Reply-To: <ee5185b1-7820-b2ac-1bde-da1c761fa594@jeffhostetler.com>

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.

Thanks for the help,

Isaac

On Wed, Jan 24, 2018 at 4:00 PM, Jeff Hostetler <git@jeffhostetler.com> wrote:

Show 25 quoted lines

>
>
> On 1/24/2018 2:59 PM, Isaac Hier wrote:
>>
>> Jeff, no worries, fair enough. I know https://github.com/grpc/grpc
>> uses a shared file to generate code for several build systems instead
>> of maintaining them individually. I plan on doing the work anyway just
>> because I have my own reasons to use CMake in Git (for packaging in
>> https://github.com/ruslo/hunter is my main motive here). Whether or
>> not it is maintained upstream is not a real concern for me at the
>> moment.
>
> [...]
>>
>> I'll see how the Windows build currently works and if that makes
>> sense, maybe I'll try using that build generator here too.
>>
>> Thanks for the feedback,
>>
>> Isaac
>
>
> Look at the "vcxproj:" target in config.mak.uname (in the GfW repo).
>
> Jeff