[pacman-dev] CVS update of pacman-lib (TODO.aaron)
juergen at hoetzel.info
Wed Feb 7 17:42:52 EST 2007
On Wed, Feb 07, 2007 at 01:46:06PM -0600, Aaron Griffin wrote:
> On 2/7/07, Jürgen Hötzel <juergen at hoetzel.info> wrote:
> > On Wed, Feb 07, 2007 at 01:09:46PM -0500, Aaron Griffin wrote:
> > > +* feature for 3.1: revamp the autotools system. I'd LOVE to use a manual system
> > > + like wmii and friends do. It'd be real nice if we could just do away with
> > > + autotools altogether.
> > Whats the problem with autotools/libtools?
> Technically, nothing. It's more personal preference than anything
> else. I like manual methods. make is a great system and really
> doesn't need layer upon layer to work. There are many very large
> projects out there which don't need autotools and get away with it
> flawlessly (i.e. the kernel).
> My TODO list isn't set in stone, it's more or less things I'd *like* to do.
> ftjam, perforce jam, bjam, cmake, scons, all of them - they all
> overcomplicate the process it seems. But again, this is just my
> opinion which isn't generally the opinion of everyone else.
People often get religious about build systems (like version control
systems ;-)) I prefer to discuss about real code and portability: This is a
real benefit for end users!
Autotools seems over-sized for a small project like libpacman. The real
advantage of the autotools system is portability. POSIX conformant
configuration scripts create POSIX conformant makefiles. And i hope one day
libpacman is used on more platforms than just GNU/Linux.
Automake relieves developers from all the details about generating portable
standards-compliant Makefiles. This is ease not pain.
GNU autotools is the defacto standard build system and other
developers/distributions will more likely adopt adopt libpacman if it
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the pacman-dev