<div dir="ltr">This is a very interesting discussion. If I can chime in, I agree with general sentiment that maintaining only one build system is less maintenance and easier to document. I as one of the users of CMake and also one of the developers of CMake, have used CMake in some very complicated ways. If there are any roadblocks  that exists then I am more happy to discuss them and see if we can push changes to CMake and make then work for  Proj4. <div><br></div><div>- Aashish<br><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 22, 2017 at 6:34 PM Howard Butler <<a href="mailto:howard@hobu.co">howard@hobu.co</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jun 22, 2017, at 3:57 PM, Kristian Evers <<a href="mailto:kreve@sdfe.dk" target="_blank">kreve@sdfe.dk</a>> wrote:</div><div><div class="m_-1189708495065447598WordSection1" style="font-family:HelveticaNeue;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span><br><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">><span class="m_-1189708495065447598Apple-converted-space"> </span></span><span lang="EN-US">Ditching manually-constructed and out-of-date nmake for cmake seems fine to me (ooh, CMake gives me project files now!), but ditching autotools that has worked for people for decades does not. That change would ripple into packagers and the distros for little or no appreciable benefit. <u></u><u></u></span></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I won’t claim to be an expert  in CMake, quite the opposite really, but I was under the impression that it  would be possible to set up CMake in a way so that it mimics the autotools behavior exactly when UNIX makefiles are generated. I am completely wrong here?<u></u><u></u></span></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">The benefit would be to limit the amount of code we have to maintain. It would only benefit us, true, but it would also free time that can be spend improving the overall project instead of maintaining status quo. I don’t feel too strongly about this, I just wanted to throw it out there while I was at it.</span></div></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>CMake can produce a somewhat passable facsimile to autotools behavior, but there are many nuances and autotools features that CMake doesn't support or support in the same way. These things matter to the distribution packagers and maintainers, and I've found it's often more trouble to make CMake behave the way they need than it is to just provide an autotools layout implementation. That situation in 2017 is better than it was in 2008 when I started using CMake, but it is still a friction point.</div></div><div style="word-wrap:break-word"><div><br></div><div><blockquote type="cite"><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> </span><span lang="EN-US">but I must say I'm very skeptical that we can actually *remove* anything -- especially headers with ambiguous public vs. private behavior that people now depend upon<u></u><u></u></span></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span lang="EN-US"> </span></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I get that. On the other hand I fear that we will be locked in place forever if we don’t allow breaking stuff once in a while. If at least we can get away with not exposing projects.h I think there will be much more room to play in the future. I hope that Even’s assessment about it not being used much is true.</span></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>Successfully burying projects.h would be enough to declare victory, if we can do so without upsetting too much. Even's analysis shows that might be possible. </div></div><div style="word-wrap:break-word"><div><br></div><div><blockquote type="cite"><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> </span><span lang="EN-US">We need to be delicate about changing things for a library such as Proj.4 only for the sake of being "better". This is an unfortunate consequence of maintaining a library that everything ultimately uses (and started using 20+ years ago). <u></u><u></u></span></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Perhaps the ambition should be to BE MUCH BETTER than previous versions on PROJ.4. So much better that other projects will benefit hugely from using the new API and update their codebase voluntarily. Eventually the problem will solve itself. I already think we are on the right track.</span></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>#1: "It's ugly, but it works, it will stay working, and it requires no more software development"</div><div>#2: "It works more smoothly, but you have to write/update software to use it, and it does the same thing as #1"</div><div><br></div><div>There must be new features that incentivize the work required to do #2. For the sake of itself is not enough. Maybe access to transformation pipelines are enough for that, I don't know. It's a frustrating reality of a very old and well-established software project with lots of implementations. The success of Proj.4 has indeed locked itself in place.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>_______________________________________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/mailman/listinfo/proj</a></blockquote></div></div></div></div>