[Proj] Coming releases of PR

[Aashish Chaudhary]

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.

- Aashish

On Thu, Jun 22, 2017 at 6:34 PM Howard Butler <howard at hobu.co> wrote:

>
> On Jun 22, 2017, at 3:57 PM, Kristian Evers <kreve at sdfe.dk> wrote:
>
> > 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.
>
> 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?
> 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.
>
>
> 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.
>
> > 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
>
> 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.
>
>
> 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.
>
> > 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).
>
> 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.
>
>
> #1: "It's ugly, but it works, it will stay working, and it requires no
> more software development"
> #2: "It works more smoothly, but you have to write/update software to use
> it, and it does the same thing as #1"
>
> 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.
>
>
>
>
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170629/416a41be/attachment.html>