NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Portable Makefile ideas





On Sat, 30 Mar 2019 at 22:15, Greg A. Woods <woods%planix.com@localhost> wrote:
At Sun, 10 Feb 2019 19:47:02 +0100, Benny Siegert <bsiegert%gmail.com@localhost> wrote:
Subject: Re: Portable Makefile ideas
>
> Perhaps take a look at CMake. I found it to be easier than expected,
> and it is common enough that package systems like pkgsrc support it
> directly.

I see I'm late to the game here, but I'd like to try to dissuade anyone
who'll hear me out to avoid CMake in any way, shape, form, or use.

It is a massive, ugly, inconsistent, and incomplete mess of C++
spaghetti, and it does not do what you think it does, no matter what you
think it does, nor how well you think you know it.

It most certainly does not produce portable Makefiles.  I'm not even
sure why it tries to claim it uses make.  It does use make, but not for
anything truly useful -- I think it uses make as nothing more than some
form of self-gratification.

In fact, unlike with GNU Autotools, it is impossible to casually build a
project that uses CMake without first installing CMake, which if you
have to, or want to, build from source can take as much as _hours_ to
do, even on a powerful modern system.  CMake is a trap.  It makes
Windows developers, and some less narrowly focused C++ developers, feel
like they're doing something to make their code more widely accessible,
but really they're just wasting cycles and and brain cells.

On the other hand unfortunately the ideals of GNU Autotools are lost on
the GNU/Linux generation, and completely inaccessible to everyone with
even narrower interests (i.e. M$-Windows and Xcode developers).  (That's
despite the fact the GNU/Linux world seems to be the main proponent of
GNU Autotools of course.  Nothing in the POSIX world has wasted more
cycles in building software than pointless reams of configure scripts.)

Personally (i.e. outside of my day job) I now only work with BSD
Makefiles.  For my portability needs it means that if pkgsrc doesn't
work on it, and if Bmake can't be easily installed manually with Simon's
MK files ready to go, then I really don't care about it.  :-)

(though unfortunately the Bmake in pkgsrc for macOS is pretty much
useless as it cannot generate shared libraries -- this is because it
does not (yet) use Simon's more portable MK files)

Not disagreeing at all with any of the previous, but I'd be really interested in a pointer to the new "more portable mk files" you mention, with a view to updating them in pkgsrc. I once tried to build using an extra option to a cmake-controlled build, and failed drastically, and I like to think I'm fairly up-to-speed with most of the rest of this kind of stuff. It would have been simpler to just spit out blandly-portable shell scripts, their use of make(1) adds nothing, as you say (much more memorably than me :) ).
 
I haven't yet tried to use mk-configure, but it stands a good chance of
adding the very few bits of integration glue not possible with just
BSDMake alone to build well written portable C code.

[[fyi, in my day job we use a semi-portable bunch of GNUMakefiles]]

Thanks,
Alistair 


Home | Main Index | Thread Index | Old Index