Comment by olliesaunders | Hacker News Reader

Comment by olliesaunders | Hacker News Reader

Parent Full thread

I’m being cynical but my experience of building from source even with automated tools is one where things going wrong and being very difficult to resolve: there’s a cyclic dependency here; this things compiles but won’t link; this thing just segfaults; you need a new version of X to build Y but Z, which is a part of X, needs an old version of Y; I know you wanted to run the latest version of X but author of Y didn’t update it to work with that new version of X so you can’t but that was the whole point of doing this thing in the first place; etc.

Nowadays I avoid building anything from source if there is a binary I can download and everytime I have to build from source I cringe in apprehension as to whether it will work or not. Too often, if something fails, I just give up.

OK, I’m not really this aiming this criticism at the LFS project. I’m really just griping about shitty this aspect of software development in general. People should be working on solutions to these problems. Or maybe this is a problem with me. I’d be interested other’s opinions.

It's easier than building something without dependencies from scratch with Visual C++ :-)

I built an LFS system when it came out years ago and it was a good learning exercise. That's the cool thing here. I wouldn't consider using the system from day to day though.

I agree with your sentiment though. A recent attempt to get sstp-client and NetworkManager-sstp working on CentOS 6.3 resulted in a long stompy walk when I couldn't get it to build without breaking the distribution due to dependency hell. I just chucked Ubuntu on the box in the end and used the vendor provided deb packages. Was much easier :-)

I've build a few LFS systems, knowing for sure I won't use it as a primary system. Nevermind : it's great for educational purpose, and I'm surely more confident in my sysadmin skills since I've did it.

I think it ha a lot to do with almost all of the software being open source. Instead of having management and organized teams we have.. binary based distributions, package management, and other tools like configuration management.

In that context we're really just solving a management problem with engineering! Machines are pretty great at following procedure and ensuring consistency after all.

This isn't just a problem with you, this is really a problem in the ecosystem of build tools, primarily those that target C/C++ code (though the problem exists with other languages and their build tools as well on a lesser scale). And I say this as someone who spent over a decade coding in nothing but C and C++ (thankfully that is in the past).

Go has essentially solved these problems, but only for Go code and in the process threw out (for now, at least) the notion of binary linkable libraries that your code can access, which may or may not be a bad thing depending upon how you feel about dynamically linkable libraries.

I don't think the problem is practically fixable on existing languages whose basic toolset wasn't built to deal with these sort of things. And there is a cultural element in addition to the technical one -- even if you managed to create such a build toolset for languages like C/C++, some (large) subset of C/C++ programmers are going to want to hold on to their hard-won mastery of all things configure/autconf/make and stick with them, even if those tools are all completely horrible (which, IMO, they are).

I built LFS about a year ago. The good thing about it, is that it tells you what specific versions of things you should use, so you know that you won't have a version compatibility issue. The bad thing is, a slightly wrong command at one point in the process leads to a cryptic error down the line.

Reply on news.ycombinator.com