[»] Build system not mentioned
by andres salomon - Jul 11th 2004 15:50:46

Check out cmake (http://www.cmake.org/) sometime. I've recently started using it for my projects, and I've found it to be very flexible.

[reply] [top]

[»] an immense number of details are embodied in auto*
by Horned Owl Flying - Feb 16th 2004 10:24:51

An immense number of details are now embodied in
the autoconf/automake/libtool system. No doubt
when these tools where fist coded, the programmer
coded for what would be "common sense". Then the
idiosyncrasies of the target systems came along
and caused bugs. Each bug is a patch in the long
history of one of the tools. To replace these
tools the history of autoconf/automake/libtool
must be understood in detail or repeated. (Those
who forget history are condemed to repeat it.)
Noone wants to do it, when there are more fun
things to do. Most of the tools suggested as
replacements do not have as wide usage as the
auto* tools. If they did have such a wide usage,
they would begin to have the long bugfix
history.In short the auto* tools are complex
because they help manage an immense amount of
complexity! They are definately easier to use
than to manage that complexity by hand or to
rewrite the auto* tools! It is unlikely that
anyone will want to rewrite those tools now.

The mice agreed that the cat should be belled.
But who will bell the cat?

--
It's been absolutely impossible to work through these Earth creatures. Their soul is too controlled. Eros (Plan 9 from outer space)

[reply] [top]

[»] hum
by Trejkaz Xaoza - Sep 24th 2003 21:05:37

Maybe what we need is just to educate every developer in creating something like an ebuild, so a single command will install any program regardless of what build system it actually uses...

It won't solve the problem, though, because then include files move, libraries move, etc. We would also need something like KDE's 'kde-config' script for every single package on the system. Better yet, if every package did it, you would just need one program reading the installation paths from a database. We already know what files each package holds, why not just store the CFLAGS a package requires to be used?

[reply] [top]

[»] Re: hum
by jasen - Jul 30th 2006 16:12:30


> It won't solve the problem, though,

> because then include files move,

> libraries move, etc. We would also need

> something like KDE's 'kde-config' script

> for every single package on the system.

something like pkg-config perhaps...
it works quite well here (linux), it's a bit of a pain
to get it working right for doing cross-compiles (MinGW)
Where working right requires it to completely ignore the native config data.

I haven't managed to get autoconf to work for cross compiling, scons can be convinced though.


[reply] [top]

---

[»] Put the blame where it belongs: Automake
by Gre.g - Sep 7th 2003 17:06:51

All the complaints in the article are PRECISELY the kinds
of complaints that autoconf programmers worked very
hard to avoid. For example, it's IMPOSSIBLE to have
version skew with autoconf because the configure script
is completely pre-generated before being shipped. As
far as the user is concerned it's a simple sh script.

ALL of these problems stem from the "automake"
monstrosity that creates many more problems than it
ever solved. Unfortunately people now tar autoconf with
the same brush as automake and libtool whenever they
run into problems with these. Sigh.

[reply] [top]

[»] Re: Put the blame where it belongs: Automake
by CLG - Oct 6th 2003 09:14:18

Yes, yes and yes ! This article doesn't apply to autoconf at all, at least from the user point of view, since the user never use autoconf. From the developper point of view autoconf is a useful set of "metaprogrammation" tool to create a shell script. When some install complains about the autoconf version it only proove that the Makefile have been generated by automake, which indeed generate Mafiles that rely on autoconf. IMHO this is an heresy. From my developper point of view I like to have the control on a minimum of 50% of the file present on a directory (ie to, at least, understand what they are there for). With makefile (generated by some custom script-shell of hand written) and autoconf, I do control everything. If I add the complete auto* chain, the work turn more difficult than it would be to write everything in plain sh. In short autoconf rules, automake sucks, and I'm happy to see that this opinion is shared by at least 1 other person in the world.

[reply] [top]

---

[»] Amen.
by dP - Sep 4th 2003 06:04:56

This is the best article I have ever read on Freshmeat!

You know, I actually miss just editing a config.h or
whatever, it seemed so much easier (when the
dependencies was <10:)

--
dP

[reply] [top]

[»] Check out MakeXS
by Gianni Mariani - Aug 26th 2003 13:54:09

I just published MakeXS which solves some of the issues you bring up.

Needless to say, I agree with many of the issues you talk about. The approach taken by MakeXS is to make it as easy as possible for the developer.

[reply] [top]

[»] Never
by Macdaddy - Aug 18th 2003 19:32:02

Has anyone else never had a single problem that Andrew points out? Or does anyone else not see any of what he points out as a problem? I've been building from source for a helluva long time and I have yet to find a auto* problem that didn't have a simple fix. Is anyone else NOT have problems?

[reply] [top]

[»] Re: Never
by jespa - Sep 10th 2003 00:16:53

Well, I must say that I usually compile all my packages manually (every gnome package, for example) and It is NOT usual to find these problems.
There is an honorable exception : I have tried 10 times to compile evolution-1.4 and it has EVERY problem described in the article. Problem whit DB3 versions, with gtkhtml-3 location, and many more....

[reply] [top]

---

[»] Re: Never
by Blake Matheny - Sep 24th 2003 14:08:59

As a project admin, I run into these problems. But that's only because I am having to generate all the configure files. As a user, you should never run into these issues using the Autotools, since the files you get have all been generated before hand. There is no need for m4, autoconf, automake, or any of the other autotools if you are an end user. The only tools you should need as an end user for compilation, are the bourne shell and a version of make. If you are a developer using the autotools, accept the fact that all the developers need to roughly be using the same version of the Autotools. Making this concession is a pretty reasonable tradeoff considering the ease it brings to your users in compilation, and the ease it brings to developers in terms of both increasing portability (autoconf does system checks I wouldn't otherwise think of) as well as decreasing the ammount of time needed for a development cycle.


> Has anyone else never had a single
> problem that Andrew points out? Or does
> anyone else not see any of what he
> points out as a problem? I've been
> building from source for a helluva long
> time and I have yet to find a auto*
> problem that didn't have a simple fix.
> Is anyone else NOT have problems?


[reply] [top]

---

[»] Jam
by Sam Thursfield - Aug 8th 2003 16:40:36

I can't say enough nice things about Jam. I use the Freetype version rather than the original (it nets me support for Windows 9x and junk).

Basically, imagine Make, but with a whole bunch of builtin rules and portability already there, so you don't have to screw around with anything. It'll even work with Autoconf :)

[reply] [top]

[»] Buildtool
by Julio M. Merino Vidal - Aug 8th 2003 02:55:32

I have seen this article has mentioned several alternatives to the auto* tools. I would like to recommend buildtool (my own project ;). It can be used to write configure scripts and makefiles in a very easy way; it provides functionality like libtool and pkgconfig, plus some other minor things...

It is a single, integrated tool, instead of multiple independant ones. And it does not generate files in the sense of auto* tools. Configure scripts and makefiles are kept short and simple and parsed at runtime.

And it will (hopefully) not suffer auto* tools versioning problems when it's marked stable ;). Cheers

[reply] [top]

[»] GConfigure
by Tim Thomas - Jul 23rd 2003 06:11:06

For those who haven't seen it yet you should try out GConfigure:

http://freshmeat.net/projects/gconfigure/?topic_id=46%2C1009

It's not a completely mature package and may require some hacking to get working on your system, but there's nothing more satisfying than being prompted by a GUI to check off your autoconf options and after clicking ok, ending up with an RPM installed on your system.

[reply] [top]

[»] Re: GConfigure
by Artichoke - Jul 24th 2003 05:42:41


> but there's nothing more
> satisfying than being prompted by a GUI
> to check off your autoconf options and
> after clicking ok, ending up with an RPM
> installed on your system.
Especially on your head-less Debian boxen :)



--
FreeShade - window shading, for Windows, for free - http://www.hmmn.org/FreeShade

[reply] [top]

---

[»] CMake
by Bill Hoffman - Jul 30th 2003 12:54:51

CMake is an open-source tool developed to stop the insanity. See www.cmake.org for information about CMake

Before developing CMake, its developers had years of experience with autoconf. CMake is truly cross platform and supports running autoconf like tests even on windows platforms without having to install a UNIX emulator. CMake does not depend on any additional tools like m4, or perl, or python. The only requirement is that CMake itself is installed. There are binaries for most platforms, and the source is C++ that can be compiled for most platforms.

CMake generates native build files. So for UNIX it generates makefiles (with full support for automatic C/C++ depend information generation), and for Windows it can generate IDE project files and various makefiles.

The input to CMake is a simple extendable command language. We have found it easy to port many autoconf based projects to CMake.

Here is a small example of some autoconf like tests in CMake:

CHECK_INCLUDE_FILE_CONCAT("sys/types.h" HAVE_SYS_TYPES_H)
CHECK_SYMBOL_EXISTS(socket "${CURL_INCLUDES}" HAVE_SOCKET)

Creating executables and libraries (shared and static) can be done with simple commands:

To create an executable:
SET(FOO_SOURCES foo.cxx bar.cxx car.cxx)
ADD_EXECUTABLE(foo ${FOO_SOURCES})

To create a library:
ADD_LIBRARY(bar ${BAR_SOURCES})

CMake also provides a nice interface to allow users to adjust build options. This avoids the problem of how to enable GTK. The interface can be programmed from the input files to cmake to give users good feedback on what they need to enable a feature.


[reply] [top]

---

[»] He's talking about automake, not autoconf
by Pierre Phaneuf - Jul 16th 2003 13:25:14

Most of the bad things he found with autoconf are actually problems in automake.

autoconf by itself doesn't make configure run itself, it doesn't check for autoconf or automake on your system, doesn't generate makefiles (it can mess an existing makefile, but it is automake that *writes* makefiles, not autoconf), etc...

My current solution (in XLPC, for example) is to avoid automake like the plague and write my own makefiles. It's a pain, but automake is so awful, it's clearly the lesser evil.

[reply] [top]

[»] On the other hand...
by Jeffrey Fulmer - Jul 12th 2003 22:45:11

If a rookie developer is intimidated by m4 and sh, then I guarantee he's not producing complex work. In that case, he can surely get by without writing an m4 macro. Out of the box, it's trivial to employ autotools to test for C funtions and determine the compiler and linker. But if a developer is smart enough to determine that a system is without strdup, is he smart enough to code around it? Probably not.

The author notes the prevalence of autotools based projects. Price is not an issue here. Autotools grabbed mindshare not because it was free, but because it was good. At a time when significant projects have switched from alternatives TO autotools, the author picked a curious moment to complain about it...

[reply] [top]

[»] Bravo! A debugger for Make? or M4?
by R. Bernstein - Jul 11th 2003 19:58:54

I commend Andrew McCall for a funny, insightful and thought-provoking Editorial. Clearly he has touched on such a sore nerve shared by many others (including myself) that the discusson provoked the most people and contains the most verbiage of any that I've read for a freshmeat editorial. And although the editorial made my day and served to vent my frustration in a entertaining way, I am also grateful to the author for having enlightened me a little on SCONS, CONS, and A-A-P.

There is a lot in the editorial and discussion I agree with and won't repeat. However I'd like to share a couple of my experiences.

I wrote a debugger for bash (http://bashdb.sourceforge.net or look on freshmeat) in large part to be able to debug configure scripts. And I felt the debugger was industrial strength when I was able to debug even the most trivial configure script. A 4-line configure script will generate hundreds of lines. In fact, the first time I tried to debug a real configure script I thought the debugger was in an infinite loop. On debugging the debugger, I realized, it just was that the configure script was 30 thousand lines long and it was just taking a long time to read the script into an array. After that I put something in the debugger to print out the line count every 1000 lines.

Shortly after feeling elevated that I could henceforth debug the configure scripts, I was immediately depressed in realizing that many times I'd like to be able to debug "make" and there is not really any sort of debugger for that. One can get verbose output, but I don't consider that a debugger which lets you stop at some point in the execution, specifiy variables to examine and run commands at that point.

Ditto, I think, for m4. (Pssst... debuggers have been around for 40 years if not more -- even older than these tools).

Of course Perl and Python both have debuggers and there are even GUI frontends for them. (I use GNU/Emacs, but check out the modernization to ddd I did with Daniel Schepler). The reason a configure script is something like 3000 lines long is precisely because lowest common denominator shell (perhaps not even POSIX) so configure can't doesn't use arrays or hash tables let alone functions or modules.

Which brings me finally to one last comment on automake - how unnaturally it seems to me to work for Perl programs or to have Perl replace parts of the automake system. I have a number of Perl projects that use automake. See for example ps-watcher.

Perl programs tend to use their own configure system: the MakeMaker module which I've found lacking for standalone programs like ps-watcher or recycle-logs. The Perl testing system I think has always been a little superior to that used by the default automake system. But somehow the two seem to me a little at odds with each other or at least they don't have provisions for working with each other; in my opinion there is something I can't really quantify that makes using the two together a little awkward. Likewise, I've used Perl for post-configure scripts (in packages written in Perl so the argument about having to install Perl is moot, because its a strong requirement of the package). Again there's something I can't really define, but it always feels a little foreign when I do this.

[reply] [top]

[»] Re: Bravo! A debugger for Make? or M4?
by R. Bernstein - Jun 13th 2004 16:47:07

Well, after about a year later and no takers on my call for a debugger for GNU Make, I've written one myself. See the freshmeat announcement here.

[reply] [top]

---

[»] Autotools are cool; new tools could be cooler
by amoe - Jul 2nd 2003 09:00:03

I think we should keep the autotools around purely on the grounds of their esotericism. They're probably the most widely used programs around to have been written in shell (raw, ancient Bourne, no functions), M4 (an arcane macro processor) and Make (syntactic tabs). And yet they've held up surprisingly well over the years, and enabled porting of C programs to *BSD and all sorts of proprietary *nixes. So much respect to autotools, because they are an extremely clever hack in the spirit of Unix.

However, if we are thinking about replacing them, we should not limit our scope to mere building: we should be sure to create a fully featured system for end-user installation as well, and one that is cross platform. This is a tough goal, but doable, and if we can deploy programs on Win, Mac and *nix with equal ease, it will be a boon to the community.

[reply] [top]

[»] Portability is always hard to achieve
by Paolo Bonzini - Jun 29th 2003 04:52:31

I completely disagree. Lack of proficiency in using the tools is not an excuse for the problems encountered when building programs. Yes, autotools (especially autoconf) do have quite a steep learning curve, but not because they involve learning m4 or unraveling 20kb Makefiles (not 20k lines of code -- that's the configure script :-), rather because a tool that helps making programs portable still asks you to know the pitfalls of portability. The mentioned book is wonderful and taught me all that I know about Autoconf, Automake and libtool: it is not a book for users, because users *would not* need to know anything about the autotools if the developers tried to learn rather than improvise.

Autoconf helps testing for features and works like a charm, but programs still have to be coded in order to degrade gracefully when such features are absent. It is surely easier to use for the developer than trying to compile the program on a thousand architectures and figuring out what's present on each of them and what's not; and if configure scripts were written sanely, it would be surely easier to use for the user than modifying a Makefile to suit his OS.

Autoconf is wonderfully extensible, but is indeed wonderfully hard to extend it *in a proper way*. So Autoconf does help testing for packages, but it does it slightly worse, because developers still have to know whether the APIs changed in different versions of the libraries and to code the appropriate tests. Anyway it gives better error messages than a compiler or linker error at make time -- if it does not, it is a bug, because a properly autoconfiscated program should *never ever* fail to build after the configure script has run.

Finally, Autoconf has evolved taking into account some of the problems mentioned in the article. config.cache is disabled by default nowadays, too bad many programs use a six-years-old version of Autoconf (2.13) only because the developer is lazy and does not want to type "autoupdate" (yes, this tool was very buggy in 2.50 but it has been completely rewritten since and is now foolproof). As a result, many configure scripts do not work under zsh (i.e. under MacOS X), are bound to use obsolete versions of Automake and libtool which carry their own share of bugs, and so on.

Any tool meant to replace the autotools would have exactly the same pitfalls of the latest Autoconf. Developers should learn to use the autotools properly instead of agreeing with users who bash against them.

[reply] [top]

[»] Re: Portability is always hard to achieve
by Harald Korneliussen - Jul 20th 2007 04:28:46


> Developers should

> learn to use the autotools properly

> instead of agreeing with users who bash

> against them.

>

I think that if almost no one manage to make a "proper" autotools project, that says more about the project than the developers. If it was easy to learn to use the autotools properly, people would have done it, and every open source project of any size would pretty soon run into a guy who said "here, I'll fix your build scripts, they're too ugly right now". That just isn't happening...

[reply] [top]

---

[»] SCons stability, autoconf functionality
by Steven Knight - Jun 23rd 2003 09:46:40

Two such solutions are "SCons" and "Cons". Both try to replace Make with something far more flexible. However, they both depend on tools which are a bit less standard than sh and m4: Perl and Python. Still, both languages are quickly becoming standard on the major Unixes. SCons is a bit less mature, but is preferred by the author of this paper. Using either allows a much clearer build process for complicated software. There is no requirement to generate a set of build instructions from a template.

A few quick items of note about SCons:

SCons is actually a lot more stable than its alpha status would suggest. We've still been tweaking end-cases in the user interface, but the base functionality has been in production use for a lot of projects for the last year and a half. And we have a very large suite of regression tests that have been implemented incrementally with the code, so functionality tends to stay fixed once a bug has been identified. Plus, we're going to go to beta very soon, anyway.

Also, the functionality in SCons at this point is almost a superset of that in Cons classic, modulo a few smaller features, the absence of which doesn't seem get in too many users' way.

Last, the current version of SCons added integrated support for autoconf-like functionality, starting with the ability to search for header files and libraries. It also provides a framework for adding your own tests, so you're not restricted only to what's available in the tool itself. The next version will add the ability to check for specific functions and types, and may add config.h-like header file generation, too.

[reply] [top]

[»] Comments and alternatives
by Bluebird - Jun 23rd 2003 07:03:26

- the author is gentle: he forgot to mention the issue with configure: imagine you type
./configure --with-qt-lib=/opt/my_qt

Configure runs and stops because he can't find Qt. Indeed, the right option with --with-qt-libs=/opt/my_qt (notice the s after lib). But why did this stupid program not check his arguments ?

Even worse, if there is a standard qt, configure will use it and I won't notice that is is not using my special version of qt because of a trivial spelling error.


- other issue: the user is a clever user and wants to separate its build tree from the sources, for example to have multiple builds with multiple options (this guy is a masochist). So he creates a directory my_build, cd to it and then runs ../configure . 50% of the free software will fail with this although configure has been thought out to handle this case.






- tmake from Trolltech tries to bite the problem from the other hand: it generates Makefiles based on a set of platform specific templates. What I like with it is that it is very simple to use, and can generate msvc (yes, I need that) project files. It is not extraordinalrily good but sufficient for my needs. It misses a few dependancies. I really regret that Trolltech has switched to a cpp based version in Qt3, the perl version was easier to hack.


- boost.org uses its own make, bjam, which looks to me even more complicated than autoconf/automake. Like tmake, it is based on a set of platform-specific templates.

- Java has its ant thing.

- autoconf/automake is even more fun with projects like KDE, where every possible hack has been used to generate extra-stuff and to patch the generated makefiles. Only two people in KDE really understand the complete makefile generation process. There is a python script in KDE, unsermake, that should replace part of automake (or is it autoconf ?)

Anyway, the author is 100% right. Automake/autoconf is an horror that only has one quality for it: it does not work too bad.

[reply] [top]

[»] Re: Comments and alternatives
by Thamer Alharbash - Jun 26th 2003 09:05:34


> - the author is gentle: he forgot to
> mention the issue with configure:
> imagine you type
> ./configure --with-qt-lib=/opt/my_qt
>
> Configure runs and stops because he
> can't find Qt. Indeed, the right option
> with --with-qt-libs=/opt/my_qt (notice
> the s after lib). But why did this
> stupid program not check his arguments
> ?
Maybe you should read the documentation sometime. Unknown options are silently passed to any other configure script run by the top level configure script.

Also there's no need to use such options to the configure script. The correct way is to override LDADD INCLUDES and PATH so that the configure script can find everything it needs.

I'll agree that there currently is no fixed way of doing things. Some configure scripts allow you to specificy an option, and others expect you to pass variables down.


> Anyway, the author is 100% right.
> Automake/autoconf is an horror that only
> has one quality for it: it does not work
> too bad.
The author like you, has not read up on the autotools documentation.



--
Thamer Alharbash

[reply] [top]

---

[»] Re: Comments and alternatives
by Bluebird - Jun 27th 2003 00:34:00

% Maybe you should read the documentation
> sometime.

Why should I ? I am just a user. The point of configure is to make it easy to distribute programs, so that the user has only simple steps to accomplish to get the program compiling: ./configure; make; make install

Now you are telling me that I should read the whold autoconf documentation just to compile a program that was distributed ?


> Unknown options are silently
> passed to any other configure script run
> by the top level configure script.

I am sure there is a reason for that. The problem is that it makes it a pain in the ass to use. So we have a tool that is a pain in the ass to use for a developer and for a user. The only thing auto* tools have good is that they work.


> Also there's no need to use such options
> to the configure script.

Then why do they provide them, can you tell me ? Why is it so standard if it is so useless ?


> The correct way
> is to override LDADD INCLUDES and PATH
> so that the configure script can find
> everything it needs.

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.


> I'll agree that there currently is no
> fixed way of doing things. Some
> configure scripts allow you to specificy
> an option, and others expect you to pass
> variables down.

And none of them report an error which the most annoying.


> The author like you, has not read up on
> the autotools documentation.

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.

[reply] [top]

---

[»] Re: Comments and alternatives
by Thamer Alharbash - Jun 28th 2003 01:58:03


> 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.

--
Thamer Alharbash

[reply] [top]

---

[»] Re: Comments and alternatives
by Laurent Bercot - Jul 27th 2003 05:20:46


> The only thing auto* tools have good is that they work.

Not even. I am a diet libc user, and I find it very difficult to link autotools-using programs against the diet libc. Why? Because the configure scripts detect that my system is Linux, and immediately assume that I'm using the glibc. Did I hear "open-mindedness" ? So, as far as portability is concerned, autotools are a failure - I can't even make them work on my i386-Linux.





> 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.

I think this is the way of wisdom. Personally, I have developed my own set of libraries hiding non-portabilities (skalibs), and build my software on top of it. Any portability problem is centralized in skalibs, and the build-time tests are understandable. I have no need for autotools, and I believe that no one has, either.

--
Laurent

[reply] [top]

---

[»] Re: Comments and alternatives
by Anton Persson - Jul 30th 2003 08:56:19

% Why should I ? I am just a user. The
> point of configure is to
> make it easy to distribute programs, so
> that the user has
> only simple steps to accomplish to get
> the program compiling:
> ./configure; make; make install

Yes, but yet you keep hacking distributions that don't compile... If a distribution does not compile you can't blame the compiler, the configure script or anything like that. It is the developers responsibility to see to that it works, and that they understand the tools that they are using.

The problem as we all know is that there is no standard for anything really, different *IXs can be very different.. And therefore we need something like autoconf/automake. It's the developers choice to make, so if something doesn't build, contact the developer about it.

I wonder how many programs that are downloaded, and then fail to build and the user just throws it in the trash. Then the user goes on and on, nagging and nagging. What he/she should do is something CONSTRUCTIVE.. It's free software, if it doesn't work either fix it, or live with it.

[reply] [top]

---

[»] Before Posting Learn
by Caffinee Hacker - Jun 22nd 2003 20:43:26

For those of you looking for a good tutorial or information about making a Makefile and configure script using auto* tools should go here http://www2.dystance.net:8080/software/docs/pdf/automake.pdf

It is a great tutorial and will teach you all you need to know to understand how great a system these auto* tools really are. Don't be scared by the length either, the first section really gives you all you need to know for a simple program and then you can skim and add the pieces you need. It's not hard so read before posting,
~Tim~

[reply] [top]

[»] A coindience?
by David Necas (Yeti) - Jun 22nd 2003 13:36:01

Most ranting comes from people who don't understand the auto* tools (proving that by writing things like you have to have automake installed to compile things or you have to know m4 to create autoconf macros) and who don't remember how software distribution looked like before autoconf and automake. Their posts reveal a primitive fear of unknown -- while one can emphatize with them, fear is not an argument. They would probably say the same anything complex they would have to learn. And creating portable C programs is inherently complex.

So you can use some HLL like Python or Java and let the language creators and porters do most of the dirty work for you. This limits the range of platforms the program will run on and the range of programs you can write -- well, you *can* write a network monitoring utility in Java, but then you can't run it on your i486 router. But of course it allows build systems with much more built-in assumptions, IOW much simplier.

Most of the other proposed solutions are no solutions at all. Trying to solve portability by seriously limiting the number of platforms is silly.

Binary packages work only in a very uniform environment (in fact, it doesn't completely work even on MS-Windows), people simply need to compile programs on not-so-standard systems.

Make replacements are nice, but I want to compile my program on IRIX, SunOS, and who-knows-what. I don't have any make replacements there.

The same holds for configure systems written in Python, or Perl, or whatever. I love Python and get along well with Perl, but too often I write a Python script and then find it doesn't run on Debian Woody, because of too old Python (not speaking about other Unices). The same for Perl. So where's the portability?

So after all, a portable build system has to use what is available -- make, shell, sed, and such simple stuff. It doesn't have to look exactly like the GNU one, but it *will* be complex and it *will* use some kind of expansion of higher-level constructs to the simple ones available everywhere.

I'm one of the of people who learned the GNU build system and I think it's great. And yes, it is because I do understand it. Except for the badly written ones, all programs using it build essentially the same way, have the same means of enabling and disabling optional stuff, Makefiles have the same targets, etc.

Of course, there are issues. So go ahead and fix them.

[reply] [top]

[»] Re: A coindience?
by PhrozenSmoke - Jun 23rd 2003 04:29:50


> Most ranting comes from people who don't
> understand the auto* tools (proving that
> by writing things like you have to have
> automake installed to compile things or
> you have to know m4 to create autoconf
> macros) and who don't remember how
> software distribution looked like before
> autoconf and automake. Their posts
> reveal a primitive fear of unknown --
> while one can emphatize with them, fear
> is not an argument. They would probably
> say the same anything complex they would
> have to learn. And creating portable C
> programs is inherently complex.
>
> So you can use some HLL like Python or
> Java and let the language creators and
> porters do most of the dirty work for
> you. This limits the range of platforms
> the program will run on and the range of
> programs you can write -- well, you
> *can* write a network monitoring utility
> in Java, but then you can't run it on
> your i486 router. But of course it
> allows build systems with much more
> built-in assumptions, IOW much
> simplier.
>
> Most of the other proposed solutions are
> no solutions at all. Trying to solve
> portability by seriously limiting the
> number of platforms is silly.
>
> Binary packages work only in a very
> uniform environment (in fact, it doesn't
> completely work even on MS-Windows),
> people simply need to compile programs
> on not-so-standard systems.
>
> Make replacements are nice, but I want
> to compile my program on IRIX, SunOS,
> and who-knows-what. I don't have any
> make replacements there.
>
> The same holds for configure systems
> written in Python, or Perl, or whatever.
> I love Python and get along well with
> Perl, but too often I write a Python
> script and then find it doesn't run on
> Debian Woody, because of too old Python
> (not speaking about other Unices). The
> same for Perl. So where's the
> portability?
>
> So after all, a portable build system
> has to use what is available -- make,
> shell, sed, and such simple stuff. It
> doesn't have to look exactly like the
> GNU one, but it *will* be complex and it
> *will* use some kind of expansion of
> higher-level constructs to the simple
> ones available everywhere.
>
> I'm one of the of people who learned the
> GNU build system and I think it's great.
> And yes, it is because I do understand
> it. Except for the badly written ones,
> all programs using it build essentially
> the same way, have the same means of
> enabling and disabling optional stuff,
> Makefiles have the same targets, etc.
>
> Of course, there are issues. So go ahead
> and fix them.
>
I disagree with this guy completely, and agree with the author COMPLETELY. I write code in a variety of languages: Python, Java, C/C++, and the whole autoconf/Makefile process has become antiquated and barbaric when compared to newer installation methods available. The author says the 'make' process just uses what's available on the system: WRONG. The problem is when every single version of the 10,000+ dependencies for a program don't line up to a 'T', the 'make' process just whines and quits. The problem with the make process is all of the dependencies. You can easily spend more time installing packages for the 'make' process than installing packages for the PROGRAM you are trying to compile: First upgrade autoconf, automake, m4, libtool, some programs require assembly compilers like nasm - so upgrade that. When you spend more time 'getting ready to install' then installing and running the program, there is a problem. Who are these people trying to run network monitoring tools on i486 'routers'? Who is using i486 as a router anyway? AOL Keyword: UPGRADE. It sounds ridiculous to make an installation process unnecessarily complicated because some loser somewhere 'MIGHT' be trying to compile the package on some Commodore-64 somewhere in the backwoods of the Tundra. Chances are, the package may compile on such a system, but will not RUN well on such a system anyways. So, we can't sacrifice progress in the name of ridiculous amounts of backwards compatiblity. I am in favor of not only moving away from the 'make' process, but moving away from raw C/C++ programs altogether. It is much better for a programs to be written in programming languages that use 'wrapped' versions of the C libraries, programming languages such as Python, Perl, etc., because it ends up (in most cases) limiting the number of dependencies. It is much easier to upgrade Python or Perl ONCE, then have to upgrade autoconf-automake-m4-libtool-etc for every single package you want to compile. Also, 'wrapped' programming languages like Python introduce something that is really missing from C: ERROR CATCHING. Which is why you see so many C/C++ programs seg-faulting. It is stupid to use an 'unwrapped' version of a programming language that assumes ANYBODY is capable of writing a 'bug free' program. There is no such thing as a 'bug free' program, as you can only test for the PRESENCE of bugs, not their absence. So, programming languages with error catching greatly add to the stability of the program. (I have yet to see a Python or Perl program 'seg fault' unless the program was making calls to some third-party wrapped C/C++ library made with swig or the like.). A Python program's dependencies tend to be simple (needs version 2.2 of Python, or version 2.3, etc.) Aside from getting stuff like PyGtk or special GUI toolkits, Python programs don't whine as much about dependencies because Python and Perl include all the necessary versions of the basic libraries in their tool kits. So, with Python you don't get whining like "need to upgrade libxml", because if a program will run with a certain version of Python it will run with the XML libraries IN that version of Python. So, I would rather spend 40 minutes upgrading Python ONCE every year or so, then having to upgrade my whole 'make' configuration every 2 weeks. Also, the 'make' process is not user-friendly for new *nix users at all. And, personally, I think if we ever want to see more people choosing *nix platforms over Windows, we have to show them something other than a bunch of tech-geek junk scrolling up a console. While people will say "well newbies shouldn't compile source packages": That is stupid, because we ALL know many times there may be only 1 or 2 programs out there that do a special task that you need to do, but, often times, no distros have binary versions available, so the user has no choice but to grab the source packages and try to compile it. (Though, if it was written in Python, Perl, Java, etc. it could be run immediately and not have to be compiled.) The same people that are saying "if you whine about the GNU make system, you have a fear of learning", have a fear of CHANGE. The time has come to move to higher-level Fourth Generation programming languages and more civilized installation processes, instead of trying to 'live in the past' and hang onto programming languages that have served their purpose. Their is nothing wrong with writing a program that relies on 'wrapped' versions of C in a language like Python/Perl, etc, because your Python program inherits the stability of the Python base. I've noticed that alot of people in the open source community love having FREE software available, but have a FEAR of using someone else's knowledge. Instead, they try to reinvent the wheel, writing C programs from scratch that 'seg fault' for all the same reasons 40,000+ C programs have seg-faulted. That's stupid when you can use Perl or Python with 'wrapped' C code that has protection against millions of known bugs, glitches, and common mistakes (and, yes, I admit I'm human and my intelligence is not flawless) and present the user with an application that is overall more stable than a raw C application. In Python, my errors are CAUGHT, not "core dumped" with an unexpected QUIT, scaring the hell out of any newbie (and, yes, I do make ERRORS- I am human and admit it. Do all of you?) Critical errors in raw C programs leave you with exactly one option when the program is running: QUIT. (Even the nice seg-fault catchers in Gnome and Kde lead to the program having to QUIT.) That's really stupid: sorry. If you used wrapped Python, Perl, or Java code - that 'wraps' the C-library, your program can continue anyways - working around the problem however you code it do so. The result: My Python programs get more positive feedback than 'bug reports'. The whole point of writing programs is to create something useful, not keep 'gdb' busy debugging core dumps. When you own up to being human, you will understand the value of using higher level languages that 'wrap' the C code, instead of writing raw C programs. It's not the quantity of programs you write, it's the QUALITY. Truth be told, a lot of open source programs written in C seem great because they are free, but the 'seg faults' and 'core dumps' caused by uncaught errors (and people trying to re-invent the wheel by coding C programs from scratch rather than constructing from a stable code-base) make a lot of open source programs not worth the tar-ball they are packaged in. Sometimes you have to put the 'do it myself from scratch' pride thing aside and start the development from a stable code base - even if it is somebody else's- like the Python, Perl, Java code base etc. No, you won't have the 'glory' of saying "I coded all of this in C...from scratch", but the program will actually WORK with way fewer bugs. By the way, BUGS also limit the portability of programs, and C/C++ programs using the 'make' process have PLENTY of them for everybody.

[reply] [top]

---

[»] Re: A coindience?
by Andrew Suffield - Jun 23rd 2003 07:30:58

I considered replying to this. Then I decided that the formatting and overuse of capitals spoke for themselves.

[reply] [top]

---

[»] Re: A coindience?
by Tim Lesher - Jun 30th 2003 12:49:42


> I considered replying to this. Then I
> decided that the formatting and overuse
> of capitals spoke for themselves.


Not to mention the 31337 user name and the full-quoting of the original message. As a Python advocate myself, this embarrasses me.

[reply] [top]

---

[»] Re: A coindience?
by Steven Knight - Jun 23rd 2003 09:21:17


> The same holds for configure systems
> written in Python, or Perl, or whatever.
> I love Python and get along well with
> Perl, but too often I write a Python
> script and then find it doesn't run on
> Debian Woody, because of too old Python
> (not speaking about other Unices). The
> same for Perl. So where's the
> portability?

We implement SCons internals in Python 1.5.2, precisely to minimize this sort of portability issue.

The issue of SCons not being implemented in a more "modern" version of Python comes up periodically, but the advantages of delivering something that works on just about every installed Python out there outweigh any small benefit we'd get from being able to use Python 2.x language features in the internal implementation. So we're probably going to stick with the lowest-common-denominator 1.5.2 release for quite a while. (You can still use Python 2.x in your SCons configuration scripts if you wish, at the expense of your own build's portability.)

Similarly, we'll be adding (soon, I hope) a pre-built package with a pre-built executable that will not require separate installation of Python to use successfully.

This is all part of our philosophy of trying to deliver a build tool that works as well as possible for as many platforms and people as possible out of the box. It's not impossible to do this just because you use a scripting language like Python, it just takes a little more work on the part of those of us implementing the build tool.


[reply] [top]

---

[»] Re: A coindience?
by MC - Jun 23rd 2003 11:06:07


> Most ranting comes from people who don't
> understand the auto* tools (proving that
> by writing things like you have to have
> automake installed to compile things or
> you have to know m4 to create autoconf
> macros) and who don't remember how
> software distribution looked like before
> autoconf and automake. Their posts
> reveal a primitive fear of unknown --
> while one can emphatize with them, fear
> is not an argument. They would probably
> say the same anything complex they would
> have to learn. And creating portable C
> programs is inherently complex.
>
> So you can use some HLL like Python or
> Java and let the language creators and
> porters do most of the dirty work for
> you. This limits the range of platforms
> the program will run on and the range of
> programs you can write -- well, you
> *can* write a network monitoring utility
> in Java, but then you can't run it on
> your i486 router. But of course it
> allows build systems with much more
> built-in assumptions, IOW much
> simplier.
>
> Most of the other proposed solutions are
> no solutions at all. Trying to solve
> portability by seriously limiting the
> number of platforms is silly.
>
> Binary packages work only in a very
> uniform environment (in fact, it doesn't
> completely work even on MS-Windows),
> people simply need to compile programs
> on not-so-standard systems.
>
> Make replacements are nice, but I want
> to compile my program on IRIX, SunOS,
> and who-knows-what. I don't have any
> make replacements there.
>
> The same holds for configure systems
> written in Python, or Perl, or whatever.
> I love Python and get along well with
> Perl, but too often I write a Python
> script and then find it doesn't run on
> Debian Woody, because of too old Python
> (not speaking about other Unices). The
> same for Perl. So where's the
> portability?
>
> So after all, a portable build system
> has to use what is available -- make,
> shell, sed, and such simple stuff. It
> doesn't have to look exactly like the
> GNU one, but it *will* be complex and it
> *will* use some kind of expansion of
> higher-level constructs to the simple
> ones available everywhere.
>
> I'm one of the of people who learned the
> GNU build system and I think it's great.
> And yes, it is because I do understand
> it. Except for the badly written ones,
> all programs using it build essentially
> the same way, have the same means of
> enabling and disabling optional stuff,
> Makefiles have the same targets, etc.
>
> Of course, there are issues. So go ahead
> and fix them.
>
I absolutely agree with you!
autoconf/automake is really the RIGHT way to do that thing.
IMHO it's insane that I'd have install python (which i personaly hate) and perl (which I like) or java (...) to build a software package.
I know that for all those RH folks Python or Perl is something as usuall like bash (which I replace by tcsh BTW ;), but for most platforms or environments it's absolutely undesirable to have them.
The autocont is designed with portability in Mind.
If the author of above article read autoconf documentation he'd probably found an answer why configure cannot check parameters at startup.


[reply] [top]

---

[»] Re: A coindience?
by Eric Lee Green - Jun 26th 2003 22:17:49


> Most ranting comes from people who don't
> understand the auto* tools (proving that
> by writing things like you have to have
> automake installed to compile things or
> you have to know m4 to create autoconf
> macros) and who don't remember how

Indeed. For example, the cryptic error message that he described is something that happens with automake, not with autoconf. I do not use automake so I don't have that problem with the various programs that I maintain -- my generated 'configure' scripts run pretty much *everywhere*, even in places that have no 'autoconf' or 'automake' installed -- such as, e.g., the typical IRIX or AIX system.

He whangs on autoconf when the real problem is automake. Typical of someone who doesn't understand the tool -- he picked on the wrong target!

(This is not to say that autoconf isn't hairy enough as it is! Just that blaming 'autoconf' for the problems of 'automake' is, as Spock would put it, "illogical"!).

[reply] [top]

---

[»] Re: A coindience?
by Juan J. Martínez - Jul 14th 2003 07:09:33


>
> % Most ranting comes from people who
> don't
> % understand the auto* tools (proving
> that
> % by writing things like you have to
> have
> % automake installed to compile things
> or
> % you have to know m4 to create autoconf
>
> % macros) and who don't remember how
>
>
> Indeed. For example, the cryptic error
> message that
> he described is something that happens
> with
> automake, not with autoconf. I do
> not use automake so I don't have that
>
> problem with the various programs that I
> maintain --
> my generated 'configure' scripts run
> pretty much
> *everywhere*, even in places that have
> no
> 'autoconf' or 'automake' installed --
> such as, e.g.,
> the typical IRIX or AIX system.
>
> He whangs on autoconf when the real
> problem is
> automake. Typical of someone who doesn't
>
> understand the tool -- he picked on the
> wrong
> target!
>
> (This is not to say that autoconf isn't
> hairy enough
> as it is! Just that blaming 'autoconf'
> for the problems
> of 'automake' is, as Spock would put it,
> "illogical"!).

I agree with you, even using automake.

I've developed a little game using SDL and it compiles and runs without problems... even in Solaris 8/9. And I'm a auto-tools novice. My be that was my lucky day? Dunno :-)

I cannot understand the article when that dude says you need auto-tools installed in order to make configure run. Well, that's not true (oh, not needed, I don't want to say what's true or false). I can realize just one case: the configure stuff is wrong.

And the fact someone distribute a wrong configure, is that auto-tools' problem? I think not :-)

No matter ant, buildtool, or whatever you wanna use is great... if the developer using it is a jerk, you'll get the same good configure & build environment you had with auto-tools :-)

May be all the problem is auto-tools are not trivial to use, and people is sometimes lazy to read the docs available. I must admit it took me about 3 hours and quite tests to be sure all the stuff was ok.

I don't agree at all with the article and I think your point of view is almost OK.

[reply] [top]

---

[»] Re: A coindience?
by smithdev - Jul 5th 2003 18:14:40

I'll chip in for the fairly sophisticated user who is new to the autotools.
I've the goat book, the potto book (that O'Reilly one) and a couple of others. I've read the info bits.
I couldn't even get started until I found the autoproject script here on Freshmeat.
I think that the best thing that could reasonably happen is cribbing an idea from the kernel community: a make menuconfig to streamline the process.

--
gentoo is all that

[reply] [top]

---

[»] agreed
by Simon Howard - Jun 21st 2003 23:41:01

I cannot stress how far I agree with this article. I have been saying to people for the past year at least that the whole auto* system is a horrible horrible mess.

I tend to find myself spending several hours for each new package I make, just setting up the build system. Once it works, it works fairly well, but it is quite simply way too complicated to set up. To be quite blatant I should NOT be spending HOURS settings this up.

I think part of the problem is that the whole system seems to be built upon layers on layers of hacks. Autoconf wasnt quite enough, so they wrote automake. Then autoheader. Autom4te. Repeat ad infinitum.

I dont think the idea of shell scripts that generate makefiles is neccesarily a bad one, but it would be nice if the whole system could be rewritten in a coherent form, preferably using sane tools (who the hell uses m4?).

It would also be nice if there was a GUI option so less experienced people could install without having to use the console.

[reply] [top]

[»] Re: agreed
by Eric Lee Green - Jun 26th 2003 22:22:04


> coherent form, preferably using sane
> tools (who the hell uses m4?).

I used to generate my entire web site via a complex set of m4 macros. Not my fault if you're not geek enough to do that :-).


> It would also be nice if there was a GUI
> option so less experienced people could
> install without having to use the
> console.

There is such a tool. It is called 'krpm' or 'gnorpm', my friend. Less experienced people should not be messing with source code, and shouldn't even know what a compiler *IS*, much less be invoking it.

[reply] [top]

---

[»] Re: agreed
by smithdev - Jul 13th 2003 14:00:25


>
> % coherent form, preferably using sane
>
> % tools (who the hell uses m4?).
>
>
> I used to generate my entire web site
> via a complex
> set of m4 macros. Not my fault if you're
> not geek
> enough to do that :-).
>
>
> % It would also be nice if there was a
> GUI
> % option so less experienced people
> could
> % install without having to use the
> % console.
>
>
> There is such a tool. It is called
> 'krpm' or 'gnorpm',
> my friend. Less experienced people
> should not be
> messing with source code, and shouldn't
> even
> know what a compiler *IS*, much less be
> invoking
> it.
>
In addition to the auto-tools and sendmail, this is about the 4th application I've ever heard of that uses m4.

I beg to differ on your Less Experienced People comment. If LEPpers don't get in and figure stuff out, how will their leprosy be cured?

--
gentoo is all that

[reply] [top]

---

[»] this is a geek world! ... or not?
by Emil Perhinschi - Jul 27th 2003 09:34:48


> I used to generate my entire web site via a complex
> set of m4 macros. Not my fault if you're not geek
>

I thought that the editorial was about tools that make common peoples' life complicated; geekishness is another issue ....


> [...]
>
> There is such a tool. It is called 'krpm' or 'gnorpm',
> my friend. Less experienced people should not be
> messing with source code, and shouldn't even
> know what a compiler *IS*, much less be invoking
> it.
>

Why should't they? Are you afraid that the less experienced people might like it, learn it and take your job ;-) ?

The editorial was also about taking care that the user, experienced or not, does not loose precious time.

I am not experienced as far as C or C++ programming is concerned, but I can survive if
$ configure;make;su;make install
does not work smothly. I don't expect the developers to see the future and make room for all the changes that might occur and I don't expect them to addapt their source code to those changes even if they lost interest in the program. I am happy if I can find out that I have to make some soft links to persuade the configure or make programs that I run RedHat and not Debian or Slackware, or that I have to modify some lines in config.h, and I am extremely gratefull when I find in config.h or some place else
# for debian users ...
or
# for slackware users ...

The contemporary "unexperienced users" are not smarter that those that caused the term "user friendly" to be coined, but neither are they using hardware worth bilions on a time sharing basis. Most of them are going to waist their personal time and run the risk of trashing hardware worth about 800$. Why not let them choose if they want to spend some time solving a problem and learning more about their tools in the process?

I am not an authority in what m4, autoconf or such other "thingies" are concerned. They worked great for me most of the time, and when I decided that I loose too much time recompiling I decided to switch from Slackware to Debian for the sake of those 9000+ of precompiled packages. I guess that m4 etc. are good enough, but if there are simpler solutions, why not use them if they can make both the developer and the end user happy?

[reply] [top]

---

[»] No ones mentioned qmake?
by Jarvis Cochrane - Jun 21st 2003 21:24:14

I agree that the whole business of building software
from source, and coping with the dependency
disaster, and coping with the differences between
platforms, is fundamentally broken.

The two best things the FSF ever did are gcc and
gtar. The two worst are their texinfo documentation
and the auto* tools.

I like the approach (and yes, I realise it's pretty
much a Qt specific thing) taken by qmake. It seems
to solve much the same problems as auto*, but
without the pointless complexity.

It's simple and it works.

Granted, it doesn't try and solve the cross platform
issue - that's palmed off to the qt library. Maybe
that's the problem with auto* - it tries to solve too
many problems at once.

Perhaps we should break *the problem* into three
parts:

1. Cross platform compatibility
2. Building the software
3. Managing dependencies

I don't know.... just my 1.5 cents worth...

[reply] [top]

[»] Re: No ones mentioned qmake?
by e8johan - Jun 22nd 2003 22:21:33


> Granted, it doesn't try and solve the
> cross platform
> issue - that's palmed of