I've found a less troublesome approach to the whole issue. I'm going to use VMWare snapshots and build, install and then run the tests. This way I can actually see what's not being done in the autoconf or make and then revert the snapshot and fix it pre-build.

It's a better way to handle the really complicated installs like Python.

I didn't really follow a lot of that. Sorry. But I do re-install Python immediately after X and Tk have been installed; just for that circular dependency thing with Python-Tk-X. Would that make a difference in your case? I have to confess that after LFS is installed, I don't test anything while building BLFS which takes me two weeks that way. I may not understand what you mean though.

I'm making a base for several different things: Server / Development / Experimental Desktops. (Read: anything but X)

1. X won't be installed.
2. Tk won't be installed because of 1.
3. Python's configure and/or make can't seem to handle non-kitchen sink setups.
(Meaning it wants everything, including your kitchen sink, installed.)

500MB of Gnu Debugger to test Python's built-in interpreted libraries? No wonder Golang is gaining such momentum, I'd expect Microsoft's Apache-Licensed C#/VB to gain ground too.

I don't like bloat... it's causing problems everywhere. Horrible mess we're starting to find ourselves in simply because no one is willing to sit on a feature stack and just maintenance it.

The way I see it is this... if something needs something else, it's going to have to be installed anyway.

Unfortunately, many developers of certain applications require sub-functions of source kits compiled against other kits as well that you may not need, want, or use, but a small part of that program uses a sub-function of a call made against that package from the parent package.

That's basically called circular dependencies. It happens a lot in UNIX. Unfortunately, you just have to do one thing...

Get over yourself, leave your pride elsewhere, and then just resolve the dependency and build your software. If you don't like X but something needs part of it installed, such as Xorg-Libs, then just install up to Xorg-Libs and continue back on the main thing. You don't always need to build all of X to resolve a dependency. Even then, if you don't like X, you also don't have to use it either. But that's my two cents.

ReaperX7,

I think you misunderstand. I do those things, work around, sort out and sometimes even break down and install something I think is superfluous.

It's not about pride... it's about a growing engineering problem.

Code just keeps getting fatter and fatter with more bugs, vulnerabilities, and more things not living up to their implied functionality. (The latter being caused by a lack of optimization. That application left open on a cell phone that runs the battery dead in 90 minutes, etc.)

I'm a firm believer in choice. That includes choice for both technical and aesthetic reasons.

What I'm not a believer in is wanton deviation and huge piles of software written for things that already exist to add "A" feature that will almost certainly go unused. That's not to say replacing from the ground up is invalid, but if system a) is rewritten identical to system b) to add extraneous feature x) that no one wants anyway...

I just feel like things are out of control and we're doomed to write on more and more code bases that grow so bug laden and unruly that there is no choice but to rewrite them every time.

The kernel manages to keep something of a fence in place, so does the GNU toolchain. But, in between it's pretty chaotic.

I don't mean just Linux either... similar stuff on windows causes a 32GB tablet to have 12 free when you buy one.

It's like that with any OS. Often you have to just knuckle under and install it, but even then sometimes I have found a dependency can at times be uninstalled if it's no longer required.

I think what it is that is needed, and I'm reasonably sure I'm not the only one, is some sort of universal library. Something that has all it needs to work under the calling of any language. Doesn't matter whether it is compiled, JIT or interpreted. I don't see many other options for reducing the bloat we see.

That sort of thing almost exists now in the form of kernel ABI's. But, it would need to exist as a less complicated interface than that.

I'm sure they've been working on that one for years at the universities, but its not so simple for obvious reasons.

I found a better way to handle these ultra complicated installs and posted that at the top.

On a general python note, I have almost always had trouble installing python apps from source mainly because python developers rarely use a proper configure script and so tracking down all the modules that the developer may have installed over the years can be a real headache, it's usually a case of install a package try it, track down the eroor, track down the package and and try again, its nice to see that more and more python developers are using setup tools to properly configure and install their apps which does make it a bit easier, personally I detest python, the forced indentation to define a code block instead of something sensible like '{}' is just one of the things I hate about it, but 'to each their own' I suppose.

Count me in on that too. In my case, I think it might have arisen from learning Perl very early in its development and sticking with it through all those years. Larry Wall's language just "feels" more natural to me and Guido van Rossum is one I just never adapted to. On the other hand, I have a colleague who first learned Python and when he has to maintain some Perl code, he tells me that it strikes him as "ugly, foreign and odd" which he condenses down to UFO.

Just my 2 cents and I'd hate for this to devolve into a Holy War.

Quite agree, I hated 'c' too when I was first forced to use it after using pascal for years, kept typing ':=' as assignment, but change as they say is the spice of life

I've never really liked plain C code myself. To me C is a dumb language, meaning it's very unoptimized, offers no real compile time benefits, and can't be really updated in syntax. C is just C, it always has been what it is and will be. It's universal and good for porting, but... that's about it.

C++ however was a vastly different story for me. It was highly optimizale, the syntax can be cleaned up more easily, and it has many compiler benefits that can be translated to various architectures.

To me the difference between C and C++ was like comparing Dueling Banjos to one of Beethoven's symphonies.

I'd like to point out that C++ came from C.

Biggest difference was that C++ was OO and C was not.

Both forms of music have their places as do the two languages. Nevertheless, as one -- like most -- who started in C and then slowly migrated to C++, I've become more conversant in the latter. Initially, I simply wrote in C++ as if it were a "better C" and ignored the OO aspects. Then as I became more familiar with the essence of the language, the object orientation naturally flowed. I think the real epiphany came when the STL was standardized, especially the really nice things available in <algorithm>. The encapsulating of data and functionality in a class has made my programs less error-prone.

On the other hand, Linus Torvalds has some strong opinions about "Aggie" Bjarne Stroustrup's language:

http://harmful.cat-v.org/software/c++/linus

...and by the way, GCC-4.9.0 is now available and will probably make it into BLFS (if not LFS) before too long. I was pleased to see that <regex> from the C++11 standard was finally implemented after all these years:

http://gcc.gnu.org/gcc-4.9/changes.html