On 1/25/2018 7: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.
Thanks for the help,
Isaac
It's been years since I've used cmake as anything other than
a casual (downstream) consumer, so I'm not sure I can answer
your questions.
The vcxproj target we have is a bit of a hack to automatically
capture the set of source files and target libraries and executables.
We don't try to capture the spirit of all of the HAVE_ and NO_ flags
when we build the *.vcxproj files. And we make some assumptions in
the generation template for the usual VC/VS settings. But then
Windows is a single target and we don't have to worry about some
things (like whether or not qsort is present).
I don't want to discourage you from attempting this. (And I realize
that my initial response might have given that impression -- I mainly
wanted to say that we don't currently have a problem on Windows with
the current Makefile situation.)
A full cmake system would let us simplify some things, but it also
complicates some things. So we might be trading one set of problems
for another. For example, the libgit2 project uses cmake. Not to
pick on them, but when I look at it, I see a lot of the same issues
(but perhaps with better syntax than the makefile).
https://github.com/libgit2/libgit2/blob/master/CMakeLists.txt
As to your portability test questions, I'm afraid I don't know.
Sorry,
Jeff
