Re: how dare you?
> I spent two - fully wasted - days
> looking for documentation, trying to
> write makefile.am, configure.in,
Have you been to the GNU website? Even if you're not a fan of texinfo you can view the on-line manuals there for all their software.
> what.ever, then trying to copy someone
> else's, and finally stuck to my old
> hand-written shell script which
> compiles. gradually I upgraded this to a
> little bigger shell script, which is
> capable of recompiling itself.
> dependancies? it's my project. it runs
> on my machines.
Everytime you work on a project you'll be writing the same scripts over and over and over. Or you could do the right thing and write your configure script for autoconf and extend it by writing your own test cases in m4.
> well, I like makefiles, I like
> configure-based projects, because of the
> advantages mentioned. but writing one is
> - at least - a pain in the ass. we
> definitely need something new, so that
> someone like me - someone programming on
> a little application - is able to make
> it public in a simple way without one
> year developers work to write an install
It's called the autotool suite. You can do something as simple as use "autoscan" and follow the automake tutorial and you'll be on your way. Took me less than a day to get my first autotool setup working.
Re: Comments and alternatives
> In this case yes, but there are other
> cases where you really
> need the option. For example, when
> compiling vim, you can
> choose with KDE, Gnome, Gtk and X gui.
> If I make a mistake
> in the spelling, I will end up with a
> Gnome GUI and no error
> notification. Not acceptable. I have to
> dig through the 20
> pages of output of configure to check
> that he has accepted
> my options.
Well I neither use GNOME nor KDE, so I have no idea what you had to go through. I avoid both desktop managers because they are not necessary as long as you use a reasonably lightweight window manager.
Also I don't use a graphical editor (emacs in console mode is fine in a large terminal).
But I digress.
If a package has you looking through tons of output without good documentation, then maybe you should ask questions on the mailing list and alert the maintainers/authors to the lack of clarity.
Free software is about choice, and freedom. Try to keep that in mind.
> And none of them report an error which
> the most annoying.
Actually this isn't always true. It depends on what mistake you make. Try "configure --foobar" and then try "configure --enable-foobar."
It's a design decision not to check the option completely because as long as it "looks" right you can pass it down to other configure scripts.
Can this be fixed? It probably can with some redesign by the autoconf poeple. Has anyone bothered to yet? No.
> Personally, I won't bother. I distribute
> my programs with a
> Makefile. Yes, it is not portable. But
> any developer can fix it in
> 20 seconds if it does not compile.
There's a lot more to be gained than just compile time options. The whole autotool set gives you incredibly good dependency checking, a slick and streamlined installation procedure, along with complete portability for building libraries (see libtool).
Redoing all of the autotools work will hurt for each project you maintain with big makefiles will hurt.
Maybe you should put that effort toward solving this problem in the autotools if it annoys you so much. Remember, free software is about freedom and choice.