More information on the X11R7.0/X11R6.9 release

Modularization should help out a lot.

For example:

I had a notebook for a while that had the 854gm (or similar, I can't recall right now.) 'Intel Extreme Blaster'. Ok. For this I had a couple XFree86/X.org servers setup for this for a long time and it had 3d acceleration and the whole works. It wasn't without issues however.

So now there was this 915 driver that was suppose to supercede the older intel drivers for video cards. So I figured I'd give the newest driver revision a try, maybe it will improve performance and stability.

Ah, but since this was DRI and X.org drivers I couldn't just install the new driver.

I had to download and install the ENTIRE X server with all new libs and the whole crapload of other stuff, when all I wanted to do was build a new driver!

I did this on a Debian system which has apt-get for everything and their moms... So it's not like it was a clean install and it's not like it wouldn't get blown away next time Debian released a bug fix for one of the X libraries. Since they can only release X-related patches as a entire new X re-install.

And what if I wanted to try out the new (at the time) x composite extensions? Or xdamage? Or if I wanted to mess around with a new input extension? or wanted to build a alternative X.org X server like XGL? Or needed a library to be built with a slightly different compile time option for whatever obscure reason?

Again I'd have to download everything, apply patches to everything, and recompile everything.

This is a huge pain.

Now with X.org's new modular system.. If there is a security update for a library, I just update that library and don't have to reinstall X. If I want to try out a new driver, I can go to X.org get the sources for that driver and build it without having to reinstall X.

Anything to make it easier and less of a hassle for end users to update their systems for security reasons is a GREAT thing.

This should make it easier to build OS-specific extensions into X. Stuff to make X work with Linux hotplug and dbus notification services without breaking anything for the BSD users.

It should make it easier to have alternative X servers and try and develop new things without breaking everything else on the developer's or curious user's systems.

I am sure that this will make it easier to build propriatory drivers for X, but it will make pretty much everything easier to deal with with X.

Auto*hell basically makes sure that a package will be almost impossible to port to any new platform that auto*hell doesn't understand, and it even fails miserably in the platforms it's supposed to understand, because it tries to guess stuff it has no clue about and it just can't know, so it blows up, and you are left with >20.000 lines of generated make vomit to swim thru.

Just because most programmers have no clue about how to properly write portable code doesn't mean auto*hell is any better.

If you don't write portable code, auto*hell will only provide a false sense of portability and make it harder for others to make your code portable, and if you write portable code there is no use for auto*hell.

Actually it's not clear that autohell would help nethack when it comes to cross-compiling. Nethack builds data files on the host and assumes that the endianness, structure sizes etc. are going to be compatible with the target. In my experience of cross-compiling projects, that's precisely the type of behaviour which made me come to loathe autohell. Not because such behaviour is mandated -- but just because it seems to be what comes naturally to most autohell users. They seem to like to run tests on the host and assume that the results will be valid for the target. Or compile for the target and then attempt to run the result on the host to find out the behaviour.

Autohell is just a tool -- it isn't inherently evil. But it's a tool which is very easy to use badly, and I'd really prefer to see it die out. Portable code and sane toolchains would be a much better answer.

I would personally pay for a licence for GNU ld for anyone and everyone who wanted it, if it meant that they'd then refrain from using libtool.

No need to make things more complicated than they already are.

For example, PostgreSQL uses autoconf. Why? Because it has a standard interface for specifying extensions and where they are. Because it has standard methods for determine if header file X exists, what is the signature of signal, does the compiler understand inline, does the function pstat exist, etc? You should have seen the mess it was before.

I think people seriously overestimate source code compatability once you step outside of gcc/glibc or linux/*BSD. PostgreSQL has some of the best code I've seen, no #ifdef scattered through the code. The code is written for sane platforms and the quirks are dealt with in the ports directory.

The results of all this creates one header file to #include and one Makefile.global with various parameters substituted. All the other Makefiles are hand written. And it definitly increases portability because now no-one needs to write code to differentiate different releases of AIX or to remember whether the C compiler can do 64-bit arithmetic, because configure simply tells you what you need to know. If a new release of BSD changed the default signal semantics to POSIX, we wouldn't even notice, because configure would set the flag and the code will be compiled accordingly.

I agree with the comments about libtool, I havn't seen a compelling reason to use it, it seems to cause more problems that it solves. PostgreSQL compiles and links shared libraries on a dozen different platforms without that much difficulty. Completely autogenerating makefiles seems like a mess too, but you don't need to do that. autoconf, by itself, *is* useful.

If you don't know how to use make, maybe you should be programming in VisualBasic or Perl.

And you can not write you programs without C compiler and assembler in hex code then you should not program at all, right ?

Fundamentally the goal of C, Make and Autotools is the same: reduce amount of hand-written code and make the same code usable on different systems. Sometimes things are not going well, C compiler miscompiles code, make forget to recompile something (especially parallel make) and creates mess, etc.

Now you happily swallow problems with C compilers and/or Make (it's not easy to write portable makefile BTW) but claim autotools do not solve real problems and are not needed. Sure: you can do anything doable with autotools with just Make and C compiler. Or with C compiler without Make. Or with just assembler. Or even with hex editor. But. With autotools you are doing less manual work. For the same end result (if you are carefull - and if you are not carefull nothing will help). What's not to like ?

Now, the question: why do you think autotools are evil, but gas, ld, gcc and make are not. They are solving the same problem!

NOf course autotools have bugs. Of course autotools can be misused. But the same is true for as, ld, make or gcc. Why are so hostile to autotools but not to your C compiler and linker ?

And if you need real problem autotools are solving - it's amount of hand-written code. Few simple lines per shared library, few lines per optional feature, etc. Portability can be achieved as well - but that's not the only goal. I'm yet to see the same thing done without autotools or some other makefile-generator with comparable amount of hand-written code.