[Proj] Coming releases of PROJ.4
schwehr at gmail.com
Mon Jun 26 09:45:21 EST 2017
+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>
> > 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
> Proj mailing list
> Proj at lists.maptools.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Proj