[Proj] Coming releases of PROJ.4

[Kurt Schwehr]

IMHO,

+1 to hobu's comments.  autoconf mostly just works for fink packagers.
cmake works well less often. scons and others just hurt.

But, I spend most of my time in bazel where I have to do everything myself
and it's often easier that way.

On Mon, Jun 26, 2017 at 6:23 AM, Howard Butler <howard at hobu.co> wrote:

>
> > On Jun 25, 2017, at 9:22 AM, Charles Karney <charles.karney at sri.com>
> wrote:
> >
> > On 06/22/2017 03:55 PM, Howard Butler wrote:
> >> 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 certainly appreciate the point that functionality (in this case,
> > autotools configuration) shouldn't be needlessly withdrawn.  However,
> > maintaining both cmake and autotools configurations entails ongoing
> > maintenance costs and I, for one, wish that autotools could be slowly
> > replaced by cmake.
>
> I don't like CMake's configuration language anymore than m4 to be honest,
> but I agree that CMake is a best-of-the-worst configuration tool,
> especially for cross-platform operations.
>
> >
> > The big benefit of cmake is that it's cross-platform.  Even though it
> > has its warts, it handles package dependencies in a (more or less)
> > uniform way, it's actively maintained, etc.
> >
> > autotools is Unix only, depends on the m4 language that hardly anyone
> > knows, and the whole mess seems to be duct-taped together.  Its big
> > advantage is that it's been around for longer.
> >
> > So my question is: aside for simple inertia (which I understand!), what
> > is stopping the Unix/Linux world adopting cmake?  Is there really
> > something about autotools that's superior to cmake for maintaining
> > packages on Linux distributions?
>
> Superior is maybe an imprecise term. I think the situation is the
> distribution packagers have adapted all of their build configurations to
> dovetail with autoconf/automake's quirks, and CMake has to mimic these
> things to be a drop-in replacement. Cross-compilation targets, special
> configuration variables, and and output install locations are all areas
> where CMake doesn't always behave or can't be made to behave exactly in the
> same way as autotools.
>
> A library that already has autotools support, especially one as
> foundational as Proj.4 now is, has a ring of configuration logic
> implemented by all of the packaging system for the myriad of distros. Many
> have built that with our autotools configuration, and if we were to yank
> that away now, we are likely to disrupt them. If we had started with CMake
> from the beginning, this wouldn't have been a problem, of course.
>
> Feedback from the distro packagers if this sentiment is contrary to
> reality would be appreciated. Maybe Proj.4 dropping autotools wouldn't be a
> big issue, but it would certainly ripple changes across a lot of
> distributions.
>
> Howard
>
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170626/0c0bd791/attachment.html>