[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#537587: ITP: makeup -- The anti-ageing build system

Package: wnpp
Severity: wishlist
Owner: Ron <ron@debian.org>

  Package name    : makeup
  Version         : 0.21
  Upstream Author : Ron <ron@debian.org>
  License         : GPLv2, with an exception for the generated files to be
                    used under whatever licence the project it's building uses.
  Programming Lang: make, m4 (autoconf)
  Description     : The anti-ageing build system

 Makeup is a build system creation/maintainance tool requiring minimal
 dependencies beyond that already installed on a system using GNU make
 and the auto* tools, but which aims to make life much easier for anyone
 maintaining such a thing for several non-trivial projects.
 Targets of the build are defined in terms of their attributes, making it
 trivial to quickly propagate build system fixes, new functional targets,
 and new system support, between many otherwise separate projects.
 Changes that have been shared are made available at the next project build.

And so before anyone asks, this isn't yet another attempt to rewrite autoconf,
rather it's a way to maintain an autoconf build system across many packages.
Over the years I found myself continually refining the boilerplate that I would
use for new projects, and perpetually annoyed that I hadn't yet 'backported'
some new nicety to older projects.  This means I get to make those changes once
and each time I go to build some old project I haven't looked at for a while,
it reminds me what new things I'm missing and offers to merge them.

It doesn't reinvent anything, it just lets me be lazier and more thorough about
keeping it all up to date, without getting dragged screaming into automake and
libtool crack.  Projects don't have to depend on it, like autoconf, it gets out
of the way for end users once it's done its thing for developers.

I've been plugging away with this since about 2003 in its latest incarnation,
and for several years before that in a few others, so it's probably about time
to think of sharing it around to anyone who might also find it useful.  I'll
probably also have a few packages using it on their way before too much longer
as well ...


Reply to: