News for hackers. Stuff that matters.
Re:How to Write Portable C Without Complicating Your Build by metafunctor on Friday March 31, 2017 @06:03AM (#14002391)
In the past, I've wrangled with autotools more than I'd care to admit. I spent very many hours indeed perfecting my automake files, configure scripts, libtool and gettext integrations, making sure you can pass in CPPFLAGS and LDFLAGS as one might expect, cross compiling, with all the .in and .in.in and .h.in files, with all the m4 macros, publishing some of my own autoconf macros, all the while figuring out how to make it all work on Linux, mingw, the various bsd derivatives, AIX, Solaris, HP-UX, OS X, Visual C compilers, and what have you.

From the developer's perspective, it is an absolute nightmare – and I consider myself a seasoned professional with the various unix-like systems and their shells. Even with this deliberate care, dedication, and time spent preparing the scripts beforehand, the build usually doesn't work properly out of the box on a new platform.

My mistake was in thinking that the value in autotools system is that you can build a system that will compile for anything. I imagined all you need to do is use (or create) feature tests to sniff out any differences between platforms, and your code will build and work anywhere.

The real value of autotools is for the user. The user can run "./configure && make && make check && make install".

Don't make the mistake I did, thinking that autotools will save you time. It absolutely will not.

Re:How to Write Portable C Without Complicating Your Build by ufo on Friday March 31, 2017 @08:17AM (#14002946)
I really wish there were an alternative to the autotools that offered that configure make install interface without the nightmarish developer experiente. Perhaps by compromising on the portability, if that is the only way.
Re:How to Write Portable C Without Complicating Your Build by js2 on Friday March 31, 2017 @12:38PM (#14005508)
CMake, SCons, maybe. This question was closed as not constructive, but the discussion looks reasonable to me:

http://stackoverflow.com/questions/600274/alternatives-to-au...

Re:How to Write Portable C Without Complicating Your Build by ryandrake on Friday March 31, 2017 @02:04PM (#14006346)
CMake was a step in the right direction, but it, too, suffers from thousands of under-documented options and fiddly behavior. In a former life I was tasked with maintaining a CMakeLists.txt for a project with multiple dependent libraries, binary blobs, open source dependencies that needed to get pulled in, and the whole thing had to be built for Windows, Linux, Mac, iOS, Android, and a handful of other lesser-known mobile platforms. I wouldn't wish that on my worst enemy.
Re:How to Write Portable C Without Complicating Your Build by cardiffspaceman on Saturday April 01, 2017 @08:30PM (#14014990)
It's not so bad. I have experience with two slightly different build systems based on CMake, which had to have customized toolchain definitions and build Cairo and WebKit. The Cairo build had a custom backend, which we integrated into Cairo's autotools. Cairo was driven using its autotools via CMake's "superproject" system.
Re:How to Write Portable C Without Complicating Your Build by contras1970 on Friday March 31, 2017 @08:58AM (#14003209)
https://github.com/roman-neuhauser/motoconf aims for that space, sadly it's very incomplete and dormant.
Re:How to Write Portable C Without Complicating Your Build by Sir_Cmpwn on Friday March 31, 2017 @09:19AM (#14003378)
I wrote a simple PoC of a simpler way to achieve something similar:

https://github.com/SirCmpwn/scmake

It's definitely not something you should use, but I hope new things take a similar approach. It's small, give it a read. Here's a somewhat more complicated project that uses it:

https://github.com/SirCmpwn/libccmd

I think from a usability standpoint (both for devs and users) it's really great but the internals could use some work.

Re:How to Write Portable C Without Complicating Your Build by medenhill on Friday March 31, 2017 @01:58PM (#14006293)
https://github.com/edenhill/mklove - mklove is end-user compatible with autoconf, without the nightmares.