6 ms·
I was excited until I saw "use autotools". edit just bought it. Quick scan reveals some GNU extensions being used, lots of tripe about pkg-config, autotools,
by meaty 14y ago
I was excited until I saw "use autotools".
edit just bought it.
Quick scan reveals some GNU extensions being used, lots of tripe about pkg-config, autotools, how to write a makefile properly without autoconf (commendable), gdb tutorial (looks resonable), short valgrind mention, unit testing, doxygen, proper assertions (woot!), short bit on VCS with git (looks reasonable), integration with python (looks reasonable), decent discussion on aliasing and copying, some serious standard-breaking things (bad), how not too shoot yourself with macros (good), linking discussion (looks ok), an odd quote from pussy riot, lots of discussion of gotchas, unicode (good!), some stuff to do with glib (yuck), OOP in C (looks ok), more glib stuff (yuck), posix threading (some mines in there), GSL (good), SQLite (good), libxml (yuck - personal preference though), libcurl (good).
So generally a mix of good and bad. Probably worth it though.
- pja 14y agoIs there an alternative that actually works?
- meaty 14y agoYeah: make and knowing what you are doing. I've built some seriously complicated stuff which builds on Linux, Solaris and FreeBSD in the past with no autoconf magic required. Autoconf is just a massive Rube Goldberg machine in disguise.
- mhd 14y agoIt arose out of a different time. Linux/Solaris/BSD are trivial, compared to all the differences of the commercial unices of ages past, with their idiosyncratic libraries, BSD vs. SysV vs. POSIX, never mind all the different compilers. People would've sacrificed their firstborn to get something running on both HP/UX and SunOS, compared to that autotools was a blessing. I think there are more papers on build systems than on sort algorithms.
- meaty 14y agoI've been through that as well. I have in the past just provided a different Makefile for each platform and run as follows: make -f Makefile.osf1 make -f Makefile.sunos4 make -f Makefile.sunos5 There is usually little difference between them - mainly compiler names/flags and the occasional def for code. Occasionally make is broken at which point you have to frig something. Keep It Simple is the #1 rule. Rule #2 is every bad thing you do will do two things bad back to you in the future.
- wrl 14y agoAgree with meaty: make and knowing what you're doing is good. Occasionally, though, my needs will be more complicated than what make can handle on its own (lots of compile-time options, for example, or lots of dependency checking), and in those cases I'll use waf. Waf is lovely and hasn't let me down, and it's easy to use for people who are used to the ./configure && make && sudo make install sequence.
- antirez 14y agoRedis uses many advanced POSIX features and some OS-dependent API (see ae.c) without autoconf, but just some minor ifdeffing business.
- deweerdt 14y agoIt depends on what you mean by works. CMake actually works for me.
- pja 14y agoI've never liked CMake, but equally I've never really been able to articulate why that is.
- apaprocki 14y agoWe decided to use gyp instead of autoconf and with some tweaking shipped a massive library that builds on Linux, Solaris, FreeBSD, OSX, AIX, HP-UX, Windows w/ it in both 32/64-bit. Definitely not for the feint of heart, but it is possible.
- jff 14y agoCheck out http://swtch.com/plan9port/ http://swtch.com/plan9port/, it's a huge project that runs on (to quote the site) Linux (x86, x86-64, PowerPC, and ARM), FreeBSD (x86, x86-64), Mac OS X (x86 and Power PC), NetBSD (x86 and PowerPC), OpenBSD (x86 and PowerPC), SunOS (Sparc). It uses a shell script to do a little bit of config, then bootstraps mk (a Bell Labs successor to make) and builds everything from some very human-readable mkfiles. When you want to build, you just untar the source and run ./INSTALL
- pja 14y agoTa, will take a look.
- dradtke 14y agoJust curious, what's wrong with glib? I happen to like it a lot, and it's a good option for getting access to data structures that other languages take for granted.
- meaty 14y agoSome horrible design and so many typedefs (gpointer being the largest yuck if you ask me). Who needs to typedef void* ? Also it leads to GObject abuse which is harmful to the soul. Ultimately, the moment you bring glib into a project it stops being C, much like the Win32 API does. I'd rather pull in libapr and apr-util.
- dradtke 14y agogobject is built on top of glib, not the other way around, and it's mostly there to make it easier to create language bindings, so there's no real reason to use it (gobject) unless you're building a library like GTK. As for the typedefs, they're there for consistency more than anything. A couple of them are legitimately useful for portability reasons, but the rest (like gpointer) are there simply to keep things looking similar in the API. Say what you will, but I see the book's apparent inclusion of glib as a plus.
- jhartmann 14y agoI'll second that, I guess I'm biased as I wrote some early gnome stuff back in the day before I started writing graphics device drivers for Precision Insight and VA Linux systems. I rather like glib, even though the gpointer thing isn't something I like too much aesthetically. Everything obviously has its warts and trade offs, nothing is perfect after all. I think glib brings a lot to the table though and with it and a few other choice libraries I can code very complex projects just as fast or faster in C as I do in Java.
- e12e 14y agoWould you care to list your other "choice libraries" ? I'm not familiar with actually programming in C (I can read C somewhat, but have never used it for a real (even small) project).
- JL2010 14y ago>some serious standard-breaking things (bad) Could you expand on this perhaps? The book sounded pretty compelling up until I read that.
- meaty 14y agoMainly GCC specific features. No C99 there. The book should have the word "GNU" wedged in it. I'd like to have seen some discussion of llvm/clang as well.
- snogglethorpe 14y agoclang and gcc are not very different from a user's point of view—clang deliberately supports a large number of gcc extensions and command-line options. For that matter, so do other C compilers (e.g. the EDG front-end, used by the intel C compiler). So really these days "gcc" is as much a common dialect of C as it is a particular compiler.
- cobrausn 14y agoI wonder why the author decided integrating with python was a better idea than, say, lua. Seems to me that lua is winning that fight, but that's just my current impression - I don't really have any solid numbers to back that up.
- TazeTSchnitzel 14y agoLua also makes it very, very easy to integrate it with a C program.
- mercurial 14y agoWhich fight? As an embedded language, Lua is more popular, yes. Outside of this, probably not.
- meaty 14y agoWell in this case, it's more integrating Python with C i.e. writing a C callable and calling it from Python. I'm not really a Lua fan personally (the confusing indice and ordinal notation scares me), but I can see why it makes sense for integration purposes. Clean, simple, to the point.
- timknauf 14y agoHaving just completed a large project with Lua, I have to say that the indice/ordinal notation thing is something that we quickly got used to. In fact, some nice succinct idioms work because elements run from 1 to arraySize (inclusive).
- zokier 14y agoAny comments on the amount of factual errors as mentioned in the 3-star amazon review?
- naner 14y agoSo basically this is a Modern C for Linux book.
- b__k 14y agoThanks for posting this. I often wondered `what are the Y-combinator people are going to say about this...?' while writing some opinionated section of the book, and the reaction seems pretty positive so far. Nobody has yet compared it to K&R... There _is_ a lot of GNU in there, but that's because there's a lot of GNU in the C ecosystem. I made an effort to neither overuse or underuse GNU tools, and this is where I wound up. Also, I made a serious effort to label anything that's GNU-specific as such, e.g., the long segment on the GNU/BSD-specific asprintf() (which I was _so_ disappointed to not see adopted in C11). Everything tests out on clang unless otherwise stated. In fact, there are little things that work better on clang, because it uses c99 out of the box. E.g., as of this writing, you'll need clang to make the example for (C11) _Generic work. If anything breaks standards without my telling you it does, you can file a bug report at O'Reilly's site for the book (or email me), and I'll fix it in later electronic versions. As for autotools, I had a sort of epiphany somewhere along the course of writing the book: it's not so bad. At the core, if you want to do something relatively simple, like set up a basic shared library, you can do so in just a few lines of Automake. It's filled with hacks and historical cruft, but as a user I...I've grown to actually like it. Also, as above, it's a huge part of the ecosystem and therefore worthy of discussion for that reason alone. If you don't like it, skip the Autotools chapter and stick with make. I won't know.
- dmlorenzetti 14y agoYou also acknowledge, in the text, that autotools gets some hate, and you justify its use and your inclusion of it in the book. My sense of the book so far-- though I've only had it for a day or two-- is that it's pretty balanced in terms of avoiding evangelical fervor for any one tool or approach.
- meaty 14y agothanks for the reply - its nice to get an insight on your perspective. My commentary above doesn't detract from my opinion which is basically: looks good, definitely didn't waste my cash. Inevitably there is stuff people disagree with - there isn't a worthy book out there that doesn't fit that description. We've needed a book like this for a while :) I look forward to future editions as well.
- aninteger 14y agoWhat do you recommend over libxml? And by libxml did you really mean libxml2? I prefer to work with a DOM parser and I don't know of anything better.
- meaty 14y agoI recommend avoiding XML. Its the most nuanced markup/data representation language there is.
- Niten 14y ago> I was excited until I saw "use autotools". People love to gripe about autotools, but if you take the time to understand it and get comfortable with what it is and is not, it will get the job done. There are alternatives like cmake, but they just suck differently. I use autotools to manage cross-platform (Linux/glibc, Linux/uclibc, mingw32, OS X) C library projects and their Python extension module wrappers, with heavy dependencies on system-specific functionality and symbol replacement (e.g., if strlcpy isn't in libc, then link in libbsd if you can find it there, otherwise compile our own copy of strlcpy.c). Autoconf is a wonderful tool for this once one RTFMs and gets over the fact that it's a bunch of helpers for writing a shell script, rather than a fully abstracted programming language of its own. Or in the words of Lennart Poettering, "every custom config/makefile/build system is worse for everybody than autotools is": https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git;a=blob_plain;f=README https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git;a=...