Slashdot Mirror

A-A-P, led by Bram Moolenaar (of vim fame) looks promising too.

And a-a-p... The coolest make replacement. a-a-p.

1. A dedicated QA staff. You should have as many testers as you have developers.
2. Tools for the QA staff to create their own automation. They don't like doing manual testing much, either, so they'll have incentive to use the tools. :-) I'll talk about the tools we use in a bit.
3. Training for the QA staff on the tools. Hire QA people capable of at least a little shell programming. And the tools they use should be not much harder than writing shell scripts.
4. A good SCM (source code management) system that provides atomic commits, so that when you fix a bug, you can tell your testers exactly what revision number it's fixed in, and they can get exactly that revision verify it in the same system you had when you fixed it.
5. A bug tracker. It doesn't have to integrate with the SCM, but if it doesn't, you should make it a hard policy that your commit log messages should say what bug number they are a fix for, and when you resolve a bug, you must say what revision the fix went into. I can't even estimate how much time this policy saves.
6. Automated rebuilds of every revision of the software. Spend a lot of time on this, it's key. It lets your testers test things the minute you fix them. That means, if you failed to fix it correctly, you'll find out SOON while the fix is still fresh in your mind, and you'll save even more time by not having to get back into the mindset of that bug. You will need special software to do it, so read on.

1. For us, our project has had 1-2 developers working full time (me, plus one additional deveoper at various times). We've also had 1-2 testers working full time. That sounds like a small project, but after two years of dev it is a lot of code, and all that code needs testing. The fulltime test staff available right from the start was absolutely not money wasted.
2. The development is done in Python, with Twisted, and so we used a combination of unit tests written by the developers and black box tests written by the testers. Because our app is primarily web, I developed my own web test system (having found no others that were suitable for use by non-programmers). This system is PBP, which is a shell-like scriptable web browser.
3. Our main tester had a little bit of C in school (she actually had forgotten most of it ;-) and a little bit of unix command line experience. This was more than enough to be able to design and build tests with PBP. Then I spent about one full day showing her how to use it and brainstorming testmaking strategies with her.
4. Subversion.
5. We've been successful with Bugzilla. If I had to start over, I probably would have used Trac, with which I've had good experiences on other projects.
6. I built a completely automatic build system using Buildbot to trigger the builds after each commit and A-A-P to script the build process.

You can find it at pmk.sourceforge.net

Or else, you can have a look at A-A-P, by nobody else than Bram Moolenaar, the author of the One True Editor, a.k.a. ViM :-)

There is also Package-framework, by Tom Lord, the author of the infamous Arch SCM.

I was about to mention SCons, too, but other people already did (it always pay to check other comments just before posting, especially on /. :-)

To sum it up : there is no shortage of alternatives to the incredibly hairy Autoconf/Automake nightmare. The problem is, people are still using them for the very same reason they use CVS instead of Arch/Subversion, or Sendmail instead of Postfix/Exim : because they're considered ``standard'' tools, and people feel more comfortable with software they know to be used by plenty of other people (millions of programmers can't all be wrong. Can they ?). I really hope they'll stop making this kind of mistakes soon, so I won't need to curse them everytime I have to debug some Autoconf breakage...

In using linux I've noticed that we have real problems with installing and uninstalling software (just image uninstalling mozilla on many platforms). This would have to be sorted before Linux could be used by the general public.
I hostly feel how ever that once this and other areas such as connecting devices have been delt with Microsoft have a big problem on there hands. Some projects that could sort the
installation/uninstalltion problem include autopackage zero-install and A-A-P

Here's a similar package funded by a dutch institution:

A-A-P

Vim's author, Bram Moolenaar, is working on a multi-platform software installer/maintainer called AAP. It's still young, but might be what the OP is looking for.

Hey, Easy Package Manager looks great. It's comparative table of existing installer/packager formats is a good answer to this topic. And it even has a FLTK graphical frontend (I love FLTK for its speed, lack of bloat and beautul API). However, it does not support Windows, which is raher logical from the design point of view.

But I found a nice list of existing packaging tools at the A-A-P which "makes it easy to locate, download, build and install software. It also supports browsing source code, developing programs, managing different versions and distribution of software and documentation." Definitely worth a look!

Hey, Easy Package Manager looks great. It's comparative table of existing installer/packager formats is a good answer to this topic. And it even has a FLTK graphical frontend (I love FLTK for its speed, lack of bloat and beautul API). However, it does not support Windows, which is raher logical from the design point of view.

But I found a nice list of existing packaging tools at the A-A-P which "makes it easy to locate, download, build and install software. It also supports browsing source code, developing programs, managing different versions and distribution of software and documentation." Definitely worth a look!

Something similar/related is A-A-P from Bram Moolenaar of vim. A 1.0 version was just released last week. It is a make+Python kind of thing. There was short article about it at osdir a few months ago.

Larry

There is also A-A-P, which is a new project built using Python. You create a recipe to execute all parts of the build. For example, to build Vim, you download the recipe, run aap, and it will download all the sources (from tarballs or CVS) and patches, apply the patches, run configure and make. Everything is cached locally so after the initial download, you no longer need a net connection to rebuild things.

Ant is basically a cross-platform scripting language that is really really weak. Really weak. I'm much looking forward to AAP by the programming god Bram Moolenar. This system is the logical extension of make into the 21st century.

Consider migrating your Makefiles to .aap files.

A-A-P may not be ready for the task yet, but as it matures, it has the potential to replace Makefiles entirely. See the multiplatform example.

A-A-P Homepage

Consider migrating your Makefiles to .aap files.

A-A-P may not be ready for the task yet, but as it matures, it has the potential to replace Makefiles entirely. See the multiplatform example.

A-A-P Homepage

I'm impressed that it's cross-platform, too.

Limitations
A-A-P is still under development, not everything works yet!

• Only Unix is currently supported.