Slashdot Mirror
Why Switch a Big Software Project to autoconf?
woggo queries: "I'm a CS grad student working on a large research project (over 1 million lines of code, supported on many platforms). The project has been under development for several years, and the build system is nontrivial for end-users. We'd like to make it easier to build our software, and I'm investigating the feasibility of migrating to GNU autoconf. I need to demonstrate that the benefits of autoconf outweigh the costs of migrating a large system of makefiles with a lot of ad-hoc kludge-enabling logic. Has anyone made a similar case to their advisor/manager? Does anyone have some good 'autoconfiscation' war stories to share? (I've already seen the Berkeley amd story and the obvious links from a google search....)" Depending on the intricacies of the build process, such a conversion might take an awful lot of work. It might be easier to put a nicer face on the "nontrivial build process", although there is something to be said for the ease of "./configure; make; make install"
You don't have to migrate the whole thing at once. Just start with a nice simple configure.in that copies Makefile.in to Makefile and config.h.in to config.h and add #includes for config.h everywhere.
Make sure new tests go in configure.in and you can slowly move across with little trouble. It should therefore be pretty easy to show that the costs are very low...
There's even more to be said for running short test programs which discern the same things that configure does, and then writing the correct .h file to disk. That way, you can write a makefile which ALWAYS works. The trouble that I have with configure is that it creates a makefile which differs from machine to machine, so that debugging it is quite difficult. Plus, if configure gets something wrong, you can make and make and make all day long, and you'll never fix it. So even though configure, in theory, saves you from having to maintain a makefile, in reality it means that everyone who runs configure may have to debug the makefile.
In other words, it's better to have one makefile, and fix the problems in the makefile, than to have to fix problems in configure or your configure specification.
If you want an example of how this can work, look at Dan Bernstein's djbdns, or qmail. On both of these, "make" Just Works(tm).
-russ
Don't piss off The Angry Economist
...there is also something to be said for double clicking 'setup.exe', then clicking 'Next' through an installer. One of the places I have always thought linux was way behind windows (especially for the new user) is with software installation. rpm -ivh?? ./configure, make, make install?? come on, you think a beginner home user will figure those out?
Here's an article on the subject, written by Uwe Ohse (you can read the original article here. Many of the problems were fixed in the mean time, but it makes an interesting read nevertheless.
autoconf config.guess, config.sub There was no source from which one could get up-to-date version of these scripts, which are used to determine the operating system type. This often caused pain: asked the openbsd port maintainers about it. (btw: there is now a canonical source for them, "ftp.gnu.org/gnu/config") autoconf takes the wrong approach The autoconf approach is, in short:
- check for headers and define some preprocessor variables based
on the result.
- check for functions and define some preprocessor variables.
- replace functions not already found in the installed libraries.
Yes, it works, albeit some details are discouraging, to but it mildly.No, it doesn't work good enough. This approach has lead to an incredible amount of badly code around the world.
Studying the autoconf documentation one learns what kind of incompatibilities exists. Using autoconf one can work around them. But autoconf doesn't provide a known working solution of such problems. Examples:
- AC_REPLACE_FUNCS, a macro to replace a function not in the
systems libraries, leads to the inclusion of rarely used
code in the package - which is a recipe for disaster.
On the developers system the function unportable() is available,
on another system it isn't? Oh well, just compile unportable.c
there and link it into the programs
...
- The same is true for AC_CHECK_FUNC(S). In this case there isn't
a replacement source file, but even worse, there's an #ifdef
inside the main sources, unless the programmers are careful
to use wrappers, which they often aren't, because compatibility
problems are often discovered very late in the testing process
(or even after release) and people are usually trying to make
the smallest possible changes.
In both cases you end up with rarely, if ever, used code in your programs. It's not dead code, it's zombie code - one day, somewhere, it will get alive again.Yes, this solves a problem. But it's overused, it's dangerous. In many cases unportable.c doesn't work on the developers system, so she can't test it. On other cases unportable.c only works correctly on _one_ kind of system, but will be used on others, too.
Yes, the often used packages _have_ been tested almost everywhere. But what about the lesser often used? ...
Keep in mind that there is no central repository of replacement functions anywhere
This is surely nothing which can be avoided completely, but it's something which has to be avoided whereever possible.
There's a solution to this problem, but it is completely different from what's used now: Instead of providing bare workaround autoconf (or a wrapper around it) ought to provide an abstraction layer above it, and a central repository for such things.
That way a programmer wouldn't use opendir, readdir, closedir directly but call they through the wrap_opendir, wrap_readdir and wrap_closedir functions (i'm aware of the fact that the GNU C library is this kind of wrapper, but it hasn't been ported to lots of systems, and you can't rip only a few functions out of it).
autoconf macros are inconsistent. For example: AC_FUNC_FNMATCH checks whether fnmatch is available and usable, and defines HAVE_FNMATCH in this case. AC_FUNC_MEMCMP checks for availability and usability of memcmp, and adds memcmp.o to LIBOBJS if that's not the case. Other examples exist. autoconf is not namespace-clean. autoconf doesn't stick to a small set of prefixes for macro names. For example it defines CLOSEDIR_VOID, STDC_HEADERS, MAJOR_IN_MKDEV, WORDS_BIGENDIAN, in addition to a number of HAVE_somethings. I really dislike that, and it seems to get worse with every new release.
My absolutely best-loved macro in this regard is AC_FUNC_GETLOADAVG, which might define the following symbols: SVR4, DGUX, UMAX, UMAX4_3, NLIST_STRUCT, NLIST_NAME_UNION, GETLOADAVG_PRIVILEGED. autoconf is large I'm feeling uneasy about the sheer size of autoconf. I'm not impressed: autoconf-2.13.tar.gz has a size of 440 KB. Add automake to that (350 KB for version 1.4). Does it _really_ have to be that large? I don't think so.
The size has a meaning - for me it means autoconf is very complicated. It didn't use to be so, back in the "good old days". And it accomplished it's task. I really don't see that it can do so much more today (i don't mean "so much more for me"). configure is large Even trivial configure scripts amount to 70 KB of size. Not much?
Compressed with gzip it's still 16 KB. Multiply that by millions of copies and millions of downloads.
No, i don't object to the size. It's perfectly ok if you get something for it. But you don't, about one half or more of each configure script can be thrown away without any lossage.
- Large parts of it just deal
with caching, which wouldn't be needed if configure wasn't so slow.
- Other parts of it are the --help output, which looks so good
...
but doesn't help usually (try it and find out what to do, without
reading README or INSTALL).
- Then there is the most bloated
command line argument parser i've ever seen in any shell script.
- Then there are many, many comments, but they aren't meant to
help you seeing what's going on inside configure, they are the
documentation for the macro maintainers (some might actually
prove to be useful, but the vast majority doesn't).
The configure scripts are the utter horror to read. There's a reason for this: configure doesn't use any "advanced" feature of the shell. But i wonder - are shell functions really unportable? And if the answer is yes: Do you really expect anything to work on that system? The problem is that a shell that old is unlikely to handle almost anything, for example large here documents.The configure scripts are the utter horror to debug. Please just try _once_ to debug 4000 lines of automatically generated shell scripts.
Note the autoconf maintainers: The road you're on is going to end soon. autoconf is badly maintained Let me clarify this first: I don't think bad about the developement. I'm missing maintainance of the already released versions. Now, at the end of 2000, almost two years have passed without a maintainance release of autoconf. 9 months have passed since a security problem has been found (in the handling of temporary files). There have more bugs been found, of course. ...
I know that nobody likes to dig in old code, but 2 years are a little bit much. automake My primary objection to automake is that automake forces me to use the same version of autoconf everywhere. Autoconf has a large number of inter-version conflicts anyway, but automake makes that situation worse, much worse.
I'd need the same version of both tools on all machines i happen to touch the Makefile.am or configure.in or any other autoconf input file on. There are a number of reasons for that, one of them is that automake used to provide some autoconf-macros during the years autoconf wasn't developed at all, and these macros are now moved to autoconf, where they belong to. But if you happen to use, say, AM_PROG_INSTALL, and later versions declare that macro obsolete
That doesn't sound too bad? Ok, but suppose
- update all those machines regulary (i'm not going to really do
that, i'd rather stick to what's installed, but anyway)
- i didn't touch a project for, say, 2 years, and then i need to
change something and release a new version. This involves changing
the version number in configure.in.
In more cases than not this will need considerable changes to configure.in. Some major, most minor - but even the minor ones need attention.I found that hard to deal with. Things were even worse since every CVS checkout tends to change time stamps, which can mean that autoreconf is run even if there's no chance been done to any autconf input file.
Don't misunderstand me: i don't attribute that to automake. I attribute it to the internal instability of autoconf. Unfortunately you can't have automake without autoconf. libtool Libtool adds an additional layer of complexity. I never had any reason to look at the insides of libtool (which proves that it worked for me). But having one project which used autoconf, automake and libtool together was enough - never again. I got exactly the same problems as i got with automake, described above, but they were worse and happened more often.
One problem with libtool is that releases don't happen very often. Libtool rarely is up to date with regards to changes on some operating systems. Which makes it difficult to use in packages meant to be really portable (to put it mildly).
A libtool script and a number of support files are distributed with every package making use of libtool, which ensures that any user can compile the package without having to install libtool before. Sounds good? But it isn't.
Another problem is the size of the libtool script. 4200 lines ...
summary
Autoconf is the weak link of the three tools, without any doubt.
Version 1 wasn't really designed, version 2 made a half-hearted
attempt of dealing with design problems. I'm not sure about the
next version.
Petru
Of course, this assumes you have a single target platform (or a very limited set, like half a dozen Windows targets). Since the question was asked for a project with multiple target platforms, double-clicking setup.exe is irrelevant.
I am an engineering grad student working on a similarly sized project. Our project is compiled on a variety of Unix platforms using automake, autoconf and libtool. As you are already compiling for multiple platforms you are 90% of the way there in determining the different needs for each compile. If you haven't already organized your build process, now would be a good time before it becomes 10M lines of code.
Autoconf and friends make it infinitely easier to compile our code. However you will have to put in a fair bit of work determining all variety of tests required to determine the idiosyncracies of each build. You are probably already doing something similar if you can build on multiple platforms.
Autoconf has been well worth the initial effort. Occasionally new compile problems crop up, but they are usually solved by the addition of another 1 line check in configure.in.
Selling autoconf should be easy. Wrestle with compile problems once getting autoconf working, or have users repeatedly wrestle with the problems without autoconf.
I'm a novice when it comes to automated build tools, but I've been impressed by Ant, from the Jakarta project by the Apache Group. From what I've read, it seems that Ant can do almost everything autoconf can, but because it's written in Java and uses XML to store its configuration, there are no cross-platform issues. I should add that I have *very* limited experience with autoconf; I've really only *used* it, not developed with it, so my opinion is a fairly uneducated one. Has anyone else used Ant and autoconf enough to make a good argument for or against Ant?
For all the fact the libtool tag line is "Do you really want to worry about linking on AIX yourself?"...
... abnormal ... but you'd think libtool would know how to do it).
I spent quite a bit of time this summer trying to use autoconf'd stuff on AIX (Gtk+). I played with a pile of recent and not-so-recent versions of libtool. It was a pain in the butt. (Granted, linking on AIX is
I think the power of the autoconf suite to make things work across "all Unices" is a bit exaggerated. Check whether it really does a good job of supporting all the platforms you need, first.
We(anon) switched to using GNU Autoconf about 2 years ago, there is nothing like it to make it easier to build on mulitple architectures. All the info you need to #ifdef your heart away is easily accessable.
"as plurdled gabbleblotchits on a lurgid bee" - Prostetnic Vogon Jeltz. (One man's humorous is another mans flamebait)
Thanks to Auto conf, some really nasty #if's in the code have been removed by a single include line, its also able to simplify code by removing 50 trillion OS specific checks from the source files and only insert it when it needs to.
Once you get over the basic learning curve hurdles, then you should be fine.
It would be nice though if there was a makefile -> autoconf converter (but that is just me).
UPS Sucks
Simply copy n' paste your favourite expression into a post!
- "Oooh! How schweet! Does it run Linux?"
- "I wonder how long it will take before Linux is ported to this puppy?"
- "I was going to write the app, but I was too lazy to do it, and waited for someone else to make it instead."
- "The GPL is great - Let's discuss it."
- "My professor said I should be using emacs..."
- "My professor said I should be using vi..."
- "It's sooo easy to port this application, why hasn't anyone done it yet? I would, but I'm too busy working on the kernel and choosing new Transformers wallpaper..."
- "If everyone was as talented a coder as me, we'd have beaten Microsoft by now!"
- "I don't care if Windows Ultra has no bugs or security flaws whatsoever, it's still worse than Linux."
- "Chyeah! Right! If it was a business requirement to use Java, they should have refused to do the project!"
- "Of course I don't use Internet Explorer. I only use it when I'm forced to, like at the office, and at school, and at home..."
- "The government can kiss my ass until they stop monitoring my phone calls... FREEEEEDOM!"
- "I can't believe you paid money for Photoshop! GIMP is way better dude!"
- "I was going to Ask Slashdot, but then I noticed that Dragonball Z was on cartoon network..."
- "I've always wanted a Japanese girlfriend so I can understand my non-dubbed/subbed anime collection..."
- "Uh! That's is such a rip off of Communication OS from Serial Experiments Lain!"
- "Why didn't Alan ask Linus about the VM? I like being on first name basis with my heroes."
- "Everyone on IRC told me Enterprise was crap. I watched it, loved it, and then told everyone I met that it was crap."
- "The government is taking away my rights! This is so like '1984'!"
- "I'm reading the preface to C for Dummies and my head already hurts..."
- "But real programmers use a CLI! Anybody who doesn't use a Common Library Injector should have got a degree like me!"
- "I'm going to code my Gamecube emulator in C, but even though I have only ever used Visual Basic Learning Edition, it should be a one banana problem and ready in the next few days."
- "I hardly think you can call me a fashion victim - I been encoding to ogg since 1994"
- "But I'm taking Computer Science at university; You WILL respect my opinion! I am the law!"
- "I may have only just graduated, and may still be looking for work, but I've got more experience than you with your '20 years of coding'!! Get A BS!"
- "I asked Neff if they would Open Source the code to my microwave, but they told me it was proprietary..."
- "I know Ada, Fortran, Cobol, C, C++, Java, HTML, Perl and RPG.... Oh, I thought you meant know *of* them..."
NickTheGreek, LondonThe traffik's blaadhy murder, but then that's part a' the charm, aint't it?!
Just do the conversion and see what's it like.
The talking about takes longer than doing it.
Then you'll really know.
I think the important difference you're forgetting is that Windows installers are installing binaries, while configure and make are building source code. A better analog in the Linux world is rpm or apt-get. There are very few programs these days that don't come with prebuilt binaries for several Linux configurations. And, no, I don't think rpm/apt-get (graphical, if you like) is much harder than setup.exe (modulo dependency satisfaction in rpm, but I would hardly consider the fact that most Windows programs are distributed with (possibly out of date) versions of a lot of libraries you already have to be advantageous).
I would argue that one of the functions of configure (aside from detecting hella shit about your build environment) is to "ask a few questions." Just doI have found that autoconf has problems when you are cross-compiling. If you are or plan to cross-compile your project, stay far away from autoconf.
/usr/share/autoconf/acspecific.m4 or not do the test!
A few macros (particularly AC_TRY_RUN, and anything that calls it) compile and run a program on the host to test for functionality. Unfortunately, there is no way to tell autoconf that you aren't going to be able to run the compiled program, because it's for your target platform.
Many of the AC_FUNC_ macros simply DIE when running in a cross-compiling environment. For example, let's cross-compile the ncftp package. The configure.in uses the AC_FUNC_SETPGRP macro. Running autoconf results in:
configure.in:146: warning: AC_TRY_RUN called without default to allow cross compiling
That's right. This macro (defined elsewhere in the autoconf package) uses AC_TRY_RUN without a default clause. So instead of recovering nicely, the configure script dies when it tries to do this test. The only way to get around this is to modify
I'm working on a relatively large project myself.
We're using a build tool called "Jam", which can be gotten from http://www.perforce.com/jam/jam.html. It does a very good job at cross platformability and is faster than make at determining include dependencies.
An open source project that uses their own version of Jam are the boost libraries at http://www.boost.org/
Enjoy!
You are comparing apple and oranges here. autoconf is a build system to support building on different platforms. And I like autoconf very much, since development libraries, includes etc lives in very different places even on different Linux systems.
setup.exe is a way of installing software to your system. Actually, it would be better to compare with Debian 'deb' files or RedHat 'rpm' files. Using apt-get should be equal to running setup.exe, assuming you have access to all deb files a certain application is dependent on.
/Jonas U
We have a monstrously large software project with home grown kludges for building on multiple platforms that is a mess of shell scripts and makesfiles. It's ugly and the time required to keep fixing and extending this system is a heavy burden. Plus, it's only tolerable to use.
I've used autoconf a little on a different smaller project and I know this much about it.
When autoconf works, it works great. As a user, there's great delight in typing those 3 magic commands and having a whole series of feature tests fire off and configure the build process. And, as a developer, every time the system works (and it works more than kludge systems), it saves me from hassles of porting to platform de jour. If you look at some fairly complicated systems such as Octave or teTeX build, it's nothing short of amazing.
However, that said, autoconf is complicated. And, you really have no choice but to learn a fair amount of the complications to deal with the issues that will inevitably come up during cross platform testing. I've mostly learned autoconf, a little of automake and almost none of libtool. The m4 macro language for defining the autoconf macros has syntax that always gives me nausea.
If you implement autoconf for your project, great. But, expect a substantial fraction of your time-savings from it to be dedicated to becoming more of an expert at autoconf, m4, sh, etc.
autoconf is better than imake, IMHO, but it sure is short of being as good as it should be. Large projects can justify the time for a person learning the intracacies of autoconf; small projects cannot, unless you happen to know it already. Learning autoconf is kind of like learning nroff just to write a man page - the time investment is more justifiable if you use your expertise to write more than one of them, or to write a really important man page.
P.S. Is there any chance that the software carpentry project will come out with something soon? Some of their early submissions for improved build tools really sounded intriguing, like Tan, an XML based description.
"Provided by the management for your protection."
One feature which I like in one Makefile system that I use, is not writing the output files, i.e., object and target files, to the source directory but somewhere else.
Writing them somewhere else makes doing backups much easier, plus the directories don't get overcrowded. You can even make source distros just with a simple tar command.
However, using Makefiles leads to really ugly bungles. Autoconf doesn't, to my knowledge, have any kind of support for this.
Any ideas about how to do it easily and cleanly?
Don't forget the Autoconf macro library and also the fact that there are thousands of free packages out there which will have configure scripts from which you can borrow - try to find packages in a similar domain to your own.
The difficulty (complexity, time taken) in maintaining a package which works on N platforms is usually proportional to N - or if you are unlucky, some small power of N like 2. What your code is really doing is trying to understand the properties of the target system and so the #ifdef __hpux__ for example in line 1249 of blurfl.c is actually trying to determine if the quux is use like this or like that. Autoconf on the other hand will produce a single preprocessor macro for driving the quux. This means that you don't have an extra 15 lines of #ifs to handle quuxes in other operating systems. Hence you may not have less #ifdeffed bits, but each of the #ifdeffed bits will be shorter.
Autoconf works differently to thge standard approach - it allows your code to work with each feature independently, and so while the normal approach is O(N) or O(N^2) in the number of suppoered OSes, the complexity of maintaining an autoconfiscated program is O(N) in the number of different features supported by the operating systems between them. The great thing about this is that Autoconf keeps these orthogonal and prevents these things from interacting too heavily, and it turns out to the the case that the total number of different features basically flattens out to some constant number even when you continue to add more supported OSes (i.e. there are only a certain total number of different ways of doing things even though each of the N operating systems can choose among X ways of doing Y things).
So, what this means is that you shold do the feasibility study as discussed above, but naturally autoconfiscating the whole system will take a while. The ideal time to do this is either
Another option to explore in combination with Autoconf is the Apache Portable Runtime. There is also Autoproject but I suspect that is a little lightweight for your needs.
Taking all the above together I suggest that you
The software carpentry project/competition had a lot of useful information and implementations of build tools. You may want to read about them to weigh the pros and cons of current build systems. You may even want to use some of their implementations.
software capentry.
SC Config is the one that is of interest to autoconf alternative, and contains links to 4 alternatives (BuildConf, ConfBase, SapCat, Tan).
With Libtool, you can be sure that shared libraries can be created, even on architectures/OS you don't have access to. That's a very important point.
Automake eases a lot the building process of clean packages for end users, with all standard targets for 'make'. It also builds Makefiles that can automatically generate
Also, Autoconf, Automake and Libtool are aware of operating-systems bugs that you probably don't know if you never worked on them. So they are your best friends to produce portable and reliable software.
{{.sig}}
- try to eliminate
all #ifdefs from your code.
- Factor out
system depencencies into their own separate files.
- Announce portability compliance requirements upfront - Posix and X/Open Unix98 should suffice. Meeting
these requirements then becomes the onus of the end user.
- Investigate using a truly portable and standard
language such as Ada for future projects.
Don't open the can of Autoconf worms if you can help it. Portability standards exist. Use them. Require your clients to meet you half-way by respecting these standards. Respecting standards is the key to portability.When I started to work for my last employer, they where using RCS and static Makefiles plus a hand-crufted make and version control system that a prior contractor had introduced. The code base for the large integrated system was about 250.000 LoC c/C++ code that ran on a number of Solaris 2.5, Linux-Boxen and Windows maschines. It used GNU-Tools and libraries quite liberally and thus was dependant on the regular introduction of external code.
But since a number of developers didn't really grasp what make was doing, they would simply copy the makefile of one of the larger subprojects and tweak until they got it working. This led to each of the about 20 sub-projects having Makefiles of about 2000 lines each. Quite unmaintainiable.
I started to use auto* for my own library that, in the beginning, was fairly separate from the other projects. More from curiosity, than actual need (I know how to use make B-) ), I put first autoconf, then automake and libtool into the code that was at that time about 20.000 LoC. I also got everybody to switch to CVS, since it supports multiple developers on the same project much better.
It worked quite well I must say. For the following reasons:
- not everybody is on a intimate level with make. If at least one person knows what they are doing the automake Macros allow encoding of that knowledge for others to use with new Makefiles.
- Specific problems with one of the plattforms may be detected, together with the activation of workarounds, in a single place, which is configure.in. One earlier poster was saying that he was having problems with changing Makefiles. I allways found that if you take the log of what happend and debug from there, changing the behavior on a given plattform as needed becomes trivial.
- You have a single place where to configure the inclusion of features, glues to other packages and the paths/names of libraries, config-files, etc. If you write your Makefiles and helper utils to do the same, it will just be duplication of effort with a smaller user-base. YMMV
- with the config.status file you can save what you have configured in a separate place and reproduce the configuration just by copying it.
The war story ends with a system that has about 2 MLoc now, and whith the help of a script that one of my fellow developers wrote, will automaticaly pull itself out of CVS (using the supplied branch) and configure and build each of the sub-packages in the proper order and install the packages on the proper machines (or at least schedule them for installation. Due to security concerns only 2 humans working together may actually install a component). My sub-project has grown to 140KLoC and the public part is on sourceforge now.Could this be done with only some make magic? Yes, if everybod knew make well. But in the real world people that really grok make are few and far between.
would your own solution handle shared libs on multiple systems? Maybe you are that good. I am not. I use libtool.
like any software there are problems with these. For instance the handling of languages like java is suboptimal in automake. But this is opensource. If you have a problem solve you itch and trust that others will solve other itches.
The Mozilla Project has a project on their website about migrating from their build system to autoconf. No Idea how far this got, but it fits your requirements of a huge project.
nikel
i've been using these tools for about 2-1/2 years. autoconf and automake have saved me a lot of hassle, i think. but i cannot recommend that anyone in their right minds uses libtool. libtool starts from a reasonable premise: the creation of shared libraries is done in very different ways on different platforms. it continues on to try to provide some standard method for developers to use when they need to do this. the problem is that for one reason or another, its gone way too far in a direction that with a little bit of objectivity is really quite bizarre. libraries end up being built in hidden directores, and are initially replaced by text files of dependencies. you have to run "libtool -gdb" if you want to debug your program without installing the libraries first. there are many wierd and obscure consequences to this design. and don't get me started on "libltdl", the libtool "portable dlopen() wrapper". in recent versions of this library (which were full of really stupid bugs) there are now hooks to replace malloc/realloc/free, for reasons that nobody on the libtool mailing list understood (probably some windows bullshit to do with calling malloc at some point during runtime linking, but who knows?). libltdl goes as far as "emulating support for run time linking even on platforms that don't support it". they are proud of this bizarre "accomplishment". libtool's basic problem is that it starts out trying to solve a goal that very few people face: trying to build a shared library on multiple platforms. because this is a very complicated task, libtool is necessarily complex. if you are writing a shared library for one or two platforms, particular where they are both fairly similar, using libtool to do this rather than doing it with your own understanding of the process can provide hours of frustration, confusion and despair. i don't see anyway forward for libtool. the sensible way to solve shared library problems is to wrap the actual linker in a new executable that operates in a standard way across platforms. this would hide the complexities and oddities of the process away from autoconf/automake and you.
if you use automake its sort of automatically there. ../myprogbin ; cd ../myprogbin ; ../myprog/configure ; make
/usr/src/myprogbin and leaves the source in /usr/src/myprog.
/usr/src/myprog> mkdir
this builds all the binaries in
ok, so actually you have to run 'autoconf' and 'automake' and 'aclocal' and etc etc etc in the source directory, and its a little confusing, but
it sort of works and leaves no binaries in the source dir.
if you just use autoconf, not automake, you have to use some special VPATH command in the Makefile.in,
this is in one of the texinfo manuals, autoconf or automake, i cant remember which.
Yep, it's old hat, but you may want to consider imake. I worked on a project where we did pretty much the same as what you're wanting to do -- using imake and did it in a couple of weeks. Multiple C++ compilers and on multiple platforms (NT, Solaris, AIX). And since you already have makefiles, you can do it a little at a time.
Yep, RPM click in Konqueror is Cool !
...
...
No, it won't be the universal solution...
Just you try with Nvidia driver.
Just you try
for you'll have to install the rpms, then modify the Xfree conf, then restart the whole shebang.
It "could" have been easier.
Could have
It takes 40+ muscles to frown, but only four to extend your arm and bitchslap the motherfucker
For large scale concurrent development, CVS is OK, but Rational Clearcase kicks the ass of every other CM system in existance. I know this from experience.
One thing which can be more or less bad is, that using autoconf makes you use gnu make as well.
Some user or developers may like their own make. If so, it will be an additional 'cost'.
I myself don't like make, it's badly suited for
multiple build targets and cross directory targets. I haven't tried any other products on a larger scale though.
One experience of this from the Mozilla project, if you change your configure tests too often, your people will have to rebuild their complete system for each change.
Pointy-cliky setups.
My current nightmare install has a hard-coded db sid (ORCL), $ORACLE_HOME, and other asst. gems all wrapped up in a NT setup.exe.
The $DOLLARS/day service engineer 'just happens' to have the exploded setup files on cd (that I am normally not allowed to see). What are they? A vb script that copies a few files and executes a few sql scripts (and not very well, mind you).
Feh. Even the oddest of Makefile setups allows me to get in and figure things out if a make fails.
--
"Remember, any tool can be the right tool." -- Red Green
This is not a solution to the current question, but is something to think about when choosing which tools to use for any project. Different languages handle portability in different ways. The C approach is a mixed blessing; the core language is portable to about any platform in existence. But almost every non-trivial program uses many many library calls, and libraries can have many inconsistencies across platforms. Even if the functionality is the same, the functions may be called different names. In the case of more advanced features such as threads or IPC, different platforms can have entirely different systems. The way I see it (I may be wrong), automake and autoconf solve the stupid inconsistencies between library functions, and tell the user if a needed library is not installed.
Other languages take different approaches. Java has a very large set of libraries that are specified to be part of the language and so must be included. The Java language is also constant between platforms. Not every platform has a conforming Java environment, but the most popular ones do. Common Lisp also has huge functionality in its standard library that is part of the language specification. OCaml has a nice standard library, and is open source. If you want your program to work in OCaml on some unsupported archictecture, you can compile it yourself. This still leaves porting the library. If the target archicture has POSIX, this is easy.
Autoconf is a tool that in the end can only make portability choices for you. In order for those choices to mean anything you have to have a need for your software to be portable (to a wide number of platforms, really), and you need to understand the real issues with writing portable software.
If you're writing for FreeBSD, Solaris, and Linux 98% of the time for application software you can write it so there are no portability issues. Why have the autoconf step when you can "make;make install"? Modern systems are not all that different for high level stuff, and are converging for medium level stuff. It's really only the low level details keeping them apart.
If on the other hand running on an old Ultrix box, and on your SCO Unix box, or on that PDP-11 in your garage is important autoconf can give you the mechanisms to make all that work but only if you know that differences between the platforms, and what changes need to happen to your code to make it work . It does no good to have autoconf check to see if bzero exists if you don't know to use memcpy as an alternative, or vice versa. A check without an alternative is just a way of bombing a little sooner than the compile stage.
The other thing autoconf can help with is optional packages. These are not portability issues per se, but rather choices that need to be made, but often aren't worth bothering a user about. Consider the application that's all command line based except for a single X app that's not really needed, just nifty. Well, if the system doesn't have X, you don't build it, and if there's no X it's unlikely the user wanted to run X apps anyway.
As far as the mechanics go, autoconf is fairly easy. Once you understand the changes that need to happen making autoconf make them for you is trivial.
yeah, well, the reason they dont statically link everything
is because then the system would need about 10 times the amount
of memory it would use with shared libraries, because
each of the libraries would be within the memory used by those 10 statically linked programs.
on the other hand, the goddamn shared libraries have such an
unstable API that alot of packages are pretty much forced to
not statically link, but rather include entire source trees of these libraries
within their projects, thus basically doing the same thing
as static linking.
the problem is somewhere related to the fact that
linux library authors dont give a rats ass about
compatibility between revisions because
1. most of them have superfast computers on phat pipes that can easily
download the latest cvs update whatever and recompile the whole fucking gnome library or whatever
and if users have problems, well, 'it works for me'.
2. they are assholes
i may well be in the minority among this crowd, but i think you should avoid autoconf like the plauge. people's most common reason for using autoconf/configure is portability, but that's a cop-out.
basically, the autoconf/configure school of portability says "forget about actually writing portable code, just write it for each variant and let the build process pick". that's whacked. you'll continually be running accross new variants, new ways in which systems are different, or just new systems. for example, i use Plan 9, which has a very good ANSI/POSIX compatability system (better than many *nix systems). despite being near-fully ANSI compliant, pretty much every autoconf fails because it doesn't recognize the output of uname or something stupid like that (of course, that says noting about when programs that claim to be ANSI or POSIX arn't, like including non-ANSI/POSIX headers, typically BSD stuff).
this school of portability also typically makes your code far less readable - littering it with ifdef's every third line - and much larger. it ends up taking much more time than just slowing down and disiplining yourself to write real portable code.
the argument 'configure ; make ; make install' is easy is stupid, as well. y'know why? 'cause 'make install' is easier. build your makefiles well. the 'install' target should have prerequisits, obviously. make will build them for install. and 'configure' is slower and more prone to failure than 'cp makefile.linux.386 makefile'. and light years more reliable. and editing an example makefile is way easier than putzing with autoconf/configure if something doesn't work. not to mention easier to debug (uh, 'echo' anyone?).
on a personal note, having done portability work a good bunch, i'd offer just a little extra advice: do not require GNU-specific stuff. don't use any of the gmake-specific features or gcc language extentions. GNU propaganda, that'll just kill your portability. and if you need something both simpler and more powerful than make, check out mk from the Plan 9 and Inferno distrubutions. Vita Nuova's got a version that runs on various unixes and win32 systems. it's very similar to make, but a bit more general and flexible. but, given that you've already got all the makefiles, i'd suggest your best bet is just sticking with plain makefiles and cleaning them up.
i speak for myself and those who like what i say.
Although in recent years the stable releases have been really good configuring, the latest development rev(.17) has been nearly impossible to configure. There lack of documentation is increasing making it worse to configure and install the latest cvs. its always linking bad object links. Referencing itself and a libray that is not there...
if you are using gnumake, that's easy:
in your Makefile.in, put:
VPATH = @srcdir@
in configure.in, you need:
AC_SUBST_FILE(srcdir)
the VPATH variable is documented in the gnumake-manuals.
sig intentionally left blank
Linus is that you? Or maybe those whacky XFree86 guys.
Special Relativity: The person in the other queue thinks yours is moving faster.
I have to say this about configure/autoconf, 99 times out of 100 everything works perfectly. I feel a tremendous weight lifted from my shoulders when I see the configure script in the output of my tar -zxvf command.
I'll even go for xmkmf before resorting to editing Makefiles by hand ala xanim. I've done editing of Makefiles but... a trip to the dentist is easy as pie in comparison.
Codifex Maximus ~ In search of... a shorter sig.
There's a book on this issue (autoconf, automake, libtool). I haven't read it. Maybe someone else can give a review.
Building shared libraries on multiple systems is a task that many people face. Any time you expect to write a shared library and have it ported across various unix-like platforms, you have this problem. Getting shared libraries working across even a few platforms is difficult enough. Linux, Solaris, and FreeBSD? Each have different requirements and quirks and (especially in the latter case) brokenness.
If you're just writing something on Linux with zero foresight as to portability, you might take the approach that "this doesn't matter," but that would be pretty naive.
Also, libtool does more than just implement a layer of portability for building shared libraries (which is its main goal). It has library dependency tracking, version maintenance, and a module loading API. These, coupled with the extreme ease of building a shared library when coupled with automake and autoconf, make it an indispensible tool.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
when you build shared libraries, by default, it compiles everything twice.
.lib directory, is supposed to some how 'keep things clean',
.la files all over the place. then i have to perform some magic voodoo
.so files without doing a 'make install', apparently because
this, along with debians 'build' scripts, has gotta be one of the best
examples of idiotic elitism of the open source 'programmer' strata... assuming that
RECOMPILING EVERYTHING TWICE IS NO BIG DEAL BECAUSE CPU AND RAM IS CHEAP. morons. absolute morons.
instead of getting the basics right, like destroying this 'feature', they instead work on,
as you said perfectly, the bizarre 'accomplishment' of emulating dynamic linking on platforms that dont have it.
when, oh when, did someone use this? wouldnt it have belonged better somewhere else?
and the hidden
but then it leaves all these goddamn
with LD_LIBRARY_PATH to get my fucking program to run against
waiting 5 minutes for a bunch of 'man pages' to copy into somewhere THEY ALREADY WERE is some how
'no big deal because cpu and ram is cheap' to the people who created this open sores monstrosity.
on the other hand, it seems to work OK once you get
past all the inane and stupid bullshit that cover it like thick goo.
I need to demonstrate that the benefits of autoconf outweigh the costs of migrating a large system of makefiles with a lot of ad-hoc kludge-enabling logic.
You sir, are ignint. It bothers me that you set out to prove something you are not sure of. You should be investigating if the benefits of autoconf outweigh the costs of migrating. Not just set out to prove something that will earn you geek points. You do a disservice to anyone simply interested in facts.
A lot of people are complaining that autoconf doesn't do this or libtool doesn't work on this platform. Please remember that all of these tools are Open Source, so you may fix them yourself and contribute the changes back to the respective projects!
Granted, not everyone has the time or the desire to fix such complex tools, but the author of the Berkeley amd story contributed many of his new tests back to these projects.
Why not improve the status quo for everyone by contributing or fixing these tools when you decide to use them? You may learn a new skill or two that you may add to your résumé in the process!
The basic idea behind imake is to use a configuration database, (i.e. some files that live in your X11 tree). This works fine, if this database is up-to-date (which is probably OK on platforms like AIX or IRIX), and all you do is X-specific.
:-). If you do not like the tests that come with autoconf, write your own.
On a typical linux-system, the imake configuration files do not know how to handle OpenGL or Motif, leave alone Qt or GTK, or non-X stuff like SSL . I have never seen an imake template that handles shared libraries in a portable way. If a software package does not support imake templates (few open source projects do), imake will not help you at all.
On the other hand, autoconf uses compile time tests to decide system characteristics. It will try to compile/link/execute little test programs, or execute shell scripts. (By the way, autoconf uses imake to find out X specific stuff
The basic problem is: autoconf will help you to check for system-specific stuff, but it will not write portable code for you.
sig intentionally left blank
Take a look at 10 Tips for Great .NET Programming. Tip #10 states that:
This seems to allow one to write a compiler/installer solution on the fly.
Gokhan Altinoren
This is not a no-brainer guaranteed win. It is easy to make autoconf do horrible, silly, things - which make your code less portable. As always, the very first thing you do should be to make your code as portable as possible to begin with; this is much, much, more efficient than any kind of configuration system.
Current versions of configure seem to sometimes produce makefiles which can't be used with classic Berkeley make, and depend on GNU extensions...
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
That was not trolling. It was a little offtopic because my point had to do with the ease or difficulty of installers in general, for all types of users, and the original poster has a different audience. Why is anything remotely pro MS considered troll on this site? Open your mind.
And I'm not sure how a setup.exe is only for a limited set- like half a dozen windows targets. For example, Morpheus is on over a million pc's. Every one of those was installed by double-clicking setup.exe (actually it is morpheus.exe). Even something as robust as the Microsoft Visual Studio uses setup.exe to install, and is also probably on a million windows machines.
...is what breaks autoconf and makes it often unusable.
Look at the PHP project. They use autoconf. Yes, it (autoconf) works most of the time pretty good for PHP.
However, you can use only certain versins of it because the older versions do not have the necessary features, and the new ones break BC or just plain have bugs that prevent PHP from building with that new version, so you are often locked in to a certain couple versions of autoconf, which is one of the main problems autoconf is supposed to fix in the first place.
It does contribute a bit to developer frustration, but, in the long run, it is much better than most other things I have seen so far, so it's probably not that bad of a choice after all...
:)
Jobs? Which jobs?
You need to move your stuff to Visual C++ dsp and dsw files, man.
Hi -
just a couple of words. Having dealt with make files a few times in the past, I can say that I would be very happy to avoid them. In dealing with a Java/JSP system under Apache, I happily made the switch to using Ant!
Ant is a wonderful improvement over the batch files, and other kludges used to produce Java builds. Anything that makes that process less manual, easier to modify, and consistent is a good thing.
The question I can't find an answer to in their doc (and I don't have time to install the tools yet) is : Can you do a parallel (multiprocess) build like gnu make?
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
An alternative to autoconf is certainly CMake , an open source cross plattform configuration and make tool developed by Kitware . This is a great tool, easy to set up and it has already successfully been used in large projects. This could reduce the effort needed for your task considerably.
From trolltech; The version that comes with qt-2 is Perl and thus as cross platform as you can probably hope for. tmakes are significantly easier to maintain directly than makefiles, configure scripts or any other beast I've looked at.
Not everybody does win only gui stuff like you do. ;-)
I think the Submitter has some kind of Server application or cross-platfor library that has to compile on multiple platforms. I wouldn't bet to much of that his project supports win32 beyond cygwin at all
The maintainers of the autotools (autoconf, automake, libtool) wrote a book to help explain the approach used by the tools. (Yes, it's called the goat book. Read the page to find out why.)
I've seen an amazing amount of crap posted in these comments; the parent article by jvl001 is one of the few good exceptions. NO tool can get it all; the autotools get you about 90%, and you have to help it the rest of the way. There are solution for just about all of the problems and red-herrings I've seen posted here, but you need to look a little farther than /. to find them.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Can you do a parallel (multiprocess) build like gnu make?
Looks like the same switch:
-jx Run up to x shell commands concurrently.
Mozilla successfully switched to autoconf a few years ago, and it has made porting much easier. we have a very extensive autoconf system...check out all the ports we do now, thanks in part to autoconf Mozilla Ports
libtool compiles every file twice because the options needed for statically linked code aren't the same as the ones needed for dinamically linked objetct files.
.o file that will be used in a shared library is built, you need to pass -fPIC in order to tell gcc to create "position independent code". With this options gcc uses a register to provide this feature. As this register is lost for normal variable optimizations, statically linked code should not be compiled with this option turned on.
When a
I've not used Jam or boost.build myself but I'm planning on diving into it in the future.
The multiplatform argument is bogus. A Setup program can be an option. It does not need to be the only installation method. Non-x86 users or x86 users who choose to can use tradition methods and x86 users who choose otherwise can use the setup program method.
Nobody looses anything. One group, which happens to be 9x% of the community has a simplification available, no harm in that.
If you're considering Jam, also take a look at Cons. It's entirely written in perl, and the "Makefiles" (called Constructs and Conscripts) are also perl, which gives incredible power and flexibility. We use it and are very happy with it. Like Jam it maintains correct dependencies automatically and it can even correctly build large projects with many interdependent subprojects.
- The library dependancy checking via AC_CHECK_LIB rocks. Why should I have to deal with the infinite possible locations for shared libraries? Autoconf deals with this nicely, and builds your -l and -L parameters for you.
- ./configure --prefix=[somewhere] makes it very easy for your users to customize the installation directory.
- AC_ARG_WITH is an execllent macro that lets you create compilation options with ease. Two of my favorites are creating debugging and profiling builds that can be removed in a production compile.
The only truly horrible feature of autoconf/automake is the function detection mechanism, as other posters have complained about. Since there is no viable replacement for the functions that are being checked, this is just plain dumb. I suggest not using this feature at all, and then only write code that is a) ansi strict, or b) only uses library functions that you checked with AC_CHECK_LIB.Following these simple rules has made it very easy for me to create sane makefiles across projects with a very large number of subdirectories and sources.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
In my experience with software projects, a straightforward build system is essential. It permits consistent builds, which is essential for debugging complex problems. It permits easy builds, which is essential for developer testing. The hardest part of programming is debugging, and good debugging requires speeding up the edit/compile/debug cycle, while ensuring that everybody still gets the same result for each build.
So I would say that no matter what, you should improve your build system.
Given that, should you use the GNU build system, which is autoconf/automake/libtool? Well, it depends. There is a definite learning curve to these tools. They are written in several different languages (sh, m4, perl) and dealing with certain problems can require understanding each of those languages and how they interact. Using these tools will not automatically make your code portable or easy to build; you have to use them correctly, and you have to understand what you are doing.
On the other hand, every other system which supports a complex build process also has a steep learning curve. There's no easy solution--if there were one, everybody would be using it.
The GNU build system is widely used, so there are a lot of people who can help you with it. The mailing lists are active and helpful. There is also a book, but I'm one of the co-authors so you'd better take that with a grain of salt.
I've converted large projects from ad hoc build systems to using the GNU build system. It's usually pretty straightforward--a matter of a week or so--but then I have a lot of experience with the tools.
I've never used most of the other build systems (e.g., Odin, Jam, ANT) for a serious project, so I can't honestly evaluate how they stack up. I can recommend against imake.
My experiences with autoconf- and libtool- based build processes is that they tend to either a) require using a gcc-based compiler or b) will only kick in optimization flags if the end user sets CFLAGS manually (and even then, the CFLAGS may not get carried over into all parts of the project).
So, depending upon your needs and just how portable you need to make your project, you might want to look at imake. While imake isn't 'simple' by any stretch of the imagination, one can take advantage of the fact that any system that ships with X11 developer packages has a working imake system that includes a good set of optimization switches set. The only big problem with imake is that a lot of folks don't set the site and/or host configuration files to change the compiler settings if they aren't using the manufacturer's compiler. [a simple #define HasGcc2 YES or is usually all it takes!]
sorry to be so off-topic but plan9/inferno are just so f*cking cool I couldn't help myself. why don't more linux users check out plan9 - I just downloaded the source and have been reading through it a little. it is just increadibly clean and packed with layer after layer of increadible ideas. for an example - read up on the window system rio, rob pike has a number of great papers on the subject.
How exactly does make (or really, GNU Make) fail to compute dependencies properly, when you give it all the information needed? (i.e, you include everything into one big Makefile, instead of using recursive make calls.)
I've never had a problem with make -j failing when plain make worked.
You may want to consider taking the approach of determining the needs of the
consumers of the source tree and then ensuring that the end-result is
repeatable, managable and empowers the consumers to maintain and extend
the solution. (i.e if the consumers are primarily Linux developers/users, then
autoconf tools are the standard).
The choice of technology used implement the build system,
in my opionion, should revolve around the consumers preferences, as this will
ensure that they can most easily make use of the solution.
If time and budget allow, using alternative technologies can achieve the desired
end-result, but will require training the consumers to achieve an empowered
system (i.e a system that does not require specialized knowledge to use, maintain
or extend)
My target build sytem consumers have been commerical companies. I use GnuMake and have
not had to use autotools yet... as all build dependencies are managed and known up-front, so
discovery is not part of the overall process or approach.
One area I find most commerically implemented build systems lacking is, to narrow of focus.
The life cycle of a source tree spans numerous organizations (dev, re, test, qa, perf, cust support,
tech marketing) yet barely meets development and release engineering needs. If building
a system for a commerical environment, talking with all consumers will help in defining requirements
for a complete system.
I've reciently gotten completely jack of make. After looking around at options I settled on Jam (actually ftjam - the freetype project's mod).
I find it brilliant. You'll have to write your own Jamerules though - check out what the boost.org project have done with it.
Highly recommended.
/..sig file not found - permission denied.
Exactly. :) Yes, one can use a tool to aggregate a Makefile, but why do that rather than using a build system that actually works as expected? This is not a slam on make. It's simply an observation that another, perhaps better tool exists.
where do i click?
First click your CD drive's icon. Then click the big seashell icon with 'setup' written below it.
Will I retire or break 10K?
There's already a library which does some of this, and chances are you already have it installed: libiberty. Perhaps its role could be expanded a bit?
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
This is a bit of a detour, since it's not about autoconf, but a different and I
think better solution to the same problem.
To start, I'd like to make my bias clear and upfront:
I'm a developer for Rogue Wave Software (www.roguewave.com), where we sell
cross platform C++ libraries. I _have_ gone ahead and talked to some of the
higher ups to make sure I don't piss anyone off, but I'm speaking for myself --
largely because I think the project I work on is fairly cool!
Over the past 10 years we've tried several solutions to deal with the
maintenance costs associated with cross platform building, including trying to
support an unwieldly makefile system like the original poster describes.
After determining that such things as autoconf didn't meet our needs, we've end
up creating our own system, called RCB.
RCB uses a java engine that generates makefiles, which it then uses to build
our libraries as well as their examples and tests. This is hooked into our
build and test manager (Batman!), allowing us to continously test various build
configurations on all of the platforms we support.
We use XML to specify how the makefiles should be built, describing both the
parts that are common, and the things that differ, such as compiler flags, etc.
RCB also uses XML to describe the "products" to be built, and which build
variations (static or dynamic linking, threading library, compiler/os, etc.)
they support.
A Java gui is used to create a reusable text file that defines what is going to
be built, and how it will be built (e.g. debug, or release?). The gui also
makes sure that only valid combinations are selected, and that the proper
required libraries are defined.
Adding new products and giving them cross-platform support and _testing_ is a
matter of creating xml that lists the source files, etc. that are a part of the
library, what other libraries it requires, and perhaps some custom flags, or
constraints on which platforms and buildtypes are supported.
I really think this is the way to go, as it has cut our maintence costs,
improved our testing, and allows more flexibility than our previous systems.
Our customers seem to generally think it's an easier system to use as well.
I couldn't imagine moving to autoconf, or going back to supporting a bunch
of platform specific makefiles
Personally, I think it would be cool if others were to use the system I've
put so much time into, although I can understand the attraction of using
more commonly available (and free!) tools. Still, I think RCB has a lot
to offer.
We've tossed around the idea of selling the system to others who face similar
problems, or perhaps even open sourcing it, but it's only just now starting to
become robust enough that this is feasible.
Feel free to send me email if you're curious about any of this.
-Jasper
phillips@roguewave.com
jasper@peak.org
So maybe migrating your entire project to Java is out of the question, but don't you wish you had its write once run anywhere capability now ?
Mozilla, everybody's favorite huge-ass software project, uses autoconf. I worked at Netscape last year, and I can tell you for sure, build issues were something I was quite glad to have been able to avoid in a project that size. There were only a couple bits of old code in Mozilla (last time I checked) left over from the Netscape 4.x days that were non-autoconf.
If you're looking for a case study to present to your pointy-hairs, look no further than Mozilla.
As someone who has been buidling a ton of the same software on different systems (OpenVMS, Linux, and Solaris) lately I must say that we should make a new tool.
:-). On OpenVMS it sux.
.h then find out exactly what I need to define as a system logical (on VMS) to make it find that. Then make sure I did that ok.
The new tool with simply be you have an xml file on each of these systems that have that systems libraries, compiler, architecture, etc. all in it kind of like how Perl's Makemaker builds a makefile but in a way that works better
I would love to see -
<oracle_8_header_files/>
as opposed to searching 25 disk arrays to find one stupid
$INC{INST_LIBS} doesn't tell the lay person a damn thing. Put it in xml with good documentation how to fix it cuz it isn't going to work for everyone.
Or maybe I will do it. Anyone else out there have any use for something like this?
Don't get me wrong, I don't build projects with a single makefile, I build them up out of hierarchical pieces where each level only knows about targets in the level below it.
(And I include "Makefile.inc" instead of "Makefile" just to make sure they don't function as regular makefiles...)
I really haven't had any problems with this, and I know it will work on any system with GNU Make. (And it's guaranteed to know all the dependencies so that make -j will work...)
I guess I'm not seeing how I could simplify this - it works for large projects without anyone knowing everything about the project, we just share some common top-level definitions, and a few conventions on how to name targets so we don't clash).
Internally, we use autoconf, automake and libtool exclusively. We found the autotools ideal for large projects, although we have made some slightly nonstandard modifications to some of the m4 and Makefile fragments.
:)
Our largest project which uses the autotools is an operating system, based around Linux, glibc and X. All of the components of the OS, with the exception of glibc, build with automake and libtool.
This, at times, wasn't at all easy, but definitely worth the effort. Building a complete OS has never been easier
You did not mention which language you use. I tried to use autoconf/automake to build a project using C++ that
I've been very satisfied with the unform way of configuring and compiling programs for Linux and Unices. It seemed viable even for big C++-Projects like KDE. "Even wxWindows uses it, and that's cross-platform for sure.", I thought.
Well, that was naive. I struggled for weeks building a build system that would work on Linux(GCC), IRIX(MipsPro), SUN(SunWS) and NT(Borland). Even the difference between GCC and the other Unix compilers became a hard problem. In the end I coded a macro that set CXXFLAGS and various other AC_SUBST variables according to the platform used. Still, the automatic dependency tracking only worked with GCC, so I started writing a script that simplified the generation of the configure script. Now I have to reconfigure each time I want to try, say, IRIX for compiling. Hmpf.
NT (with Borland) was a disaster in itself. First, I installed cygwin to have the necessary tools. The CLI of Borland differs greatly from the (more-or-less) Unix standard, so I ended up writing wrapper scripts that translated them. The final point came when I wanted to build a static library. Well, it works, with another wrapper script, but it ends up in *.a files, because I found no way to tell autoconf/automake that there might be different extensions for static libs. Maybe I'm to blame here, because I didn't dare to use libtool, but the complexity of the toolset already grew over my head.
Autoconf may have its advantages if your are using C and need to be compatible to some brain-dead machines from the seventies. For writing portable C++ programs, look for something else. Or stay with the makefiles. Good crafted makefiles still aren't that bad. You can even supply a dummy configure script, so no one downloading the thing has to change his habits ...
- The autobook examples of missing functions are trivial (meaning that the missing function is easily implemented in terms of non-missing ones--so easily, that any reasonable compiler would generate code identical to what would be generated if the package developer had written two sets of code with #ifdef HAVE_ macros). It is much easier for autoconf to simply implement strstr() in config.h if it detects that you only have index(), than it is to write, debug, and maintain one copy of every such function for every single project ever written. The code could easily fit within 'configure' itself.
- The first thing any
./configure script should do is look for a newer version of autoconf on the installer's build system, and upgrade its config.guess/config.sub/configure files appropriately (of course with a suitable --without- or --disable- option to turn this off, in case the package maintainer's version of autoconf is less broken than the package installer's version):
- Autoconf, and libtool and automake, seem to be missing support for compiling with profiling, debugging, and optimization. If you thought building cross-platform shared libraries was a pain, try building a project with working profiling or debugging support on several different compilers. I would love to have a "--enable-profiling" flag for
./configure that would automagically work consistently across platforms...
autoconf, like libtool and automake, really only solves part of the much larger problem of portability. In the limiting cases, there are only two ways to build a portable system: either use the lowest common denominator, or link to a runtime library that contains functions you need and that has been ported to every platform you care about. Things in between these extremes are really just the above rule applied to individual features--if you don't HAVE_OFF64_T, then you have to design your code for systems that don't HAVE_OFF64_T (note that simply allowing your code to bomb in implementation-defined ways when given any file bigger than 2 gigabytes is, in a technical sense, designing your code for non-HAVE_OFF64_T systems). On the other hand, if you don't HAVE_BASENAME, then you just supply your own and move on.It would be a good idea for the GNU autotools project to create a single .h file (or .h.in file) with tested replacement functions for trivial missing features. Arguably this is what GNU libc is for--acting as a translation layer between POSIX or SVID and non-compliant or broken vendor systems, and implementing missing functionality in terms of existing interfaces; however, libc isn't really used in this way.
checking for autoconf... ok ./configure
checking version of configure... 1.2.3
checking version of autoconf... 1.2.4
creating configure
restarting
Once Linux achieves world domination, autoconf will be obsolete (well, except for choosing between multiple installed versions of packages, and the --prefix/--enable/--with override options).
It would be a good idea for the GNU autotools project to create a single .h file (or .h.in file) with tested replacement functions for trivial missing features. Arguably this is what GNU libc is for--acting as a translation layer between POSIX or SVID and non-compliant or broken vendor systems, and implementing missing functionality in terms of existing interfaces; however, libc can't easily be used in this way at the moment.
-- I avoid spam by accepting only OpenPGP encrypted or signed email at this address. Clear-signed, RFC2015, heck, even
The reason why setup.exe (= installers in general) work is that they are foolproof and brainless and work the first time.
[cough cough. Well, not always. yes sometimes they don't work, sometimes they crash, sometimes you have to coax them along, sometimes they break stuff that used to work, sometimes you gotta reformat and reinstall the whole os...]
./configure; make; make install
is not the same:
1) it takes more typing
2) the chances of brainless success are lower, and you, the human installer, are assumed to have the skill to fix what's broken and coax it along.
This is why and when software is distributed as source: it's less likely to work as-is, therefore, for a programmer who can hack, the means are there to fight toward success.
A canned binary does not have this flexibility. A canned binary for x86 will not work on PowerPC and vice versa. A buildable source distro will.
I got a 4 CD set of software, bsd ports, for Mac OS X. Sources. Scanning through the whole thing one evening, I loaded up everything I thought would be useful. I mostly wanted bash. Most of it just didn't build as it was, including bash, and I didn't take the time to think and fight - if it didn't build, I went on. At the end of the evening, I'd gained one piddly little program that I don't even remember. Nothing else worked - not brainlessly at least. Some day I'll attack the bash sources again.
BY comparison, most Mac production software from apple or commercial publishers, installs a binary and works beautifully the first time. We're talking, Click. We're talking, the manual sez it won't work on a non-Apple USB, but it does anyway. But of course only for selected OS versions on PPC, and the installer took more work on the part of the publisher. There's no free lunch.
PS: I'm not worried about computers taking oover the world. They need us humans to fix the bugs and run the installers and build scripts.
Marketing-driven companies end up over-marketing their products. Engineering-driven companies end up over-engineering