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@xxxxxxxxxxxxxxxxx> wrote: > > > 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
