[pacman-dev] CVS update of pacman-lib (TODO.aaron)
Date: Wednesday, February 7, 2007 @ 13:09:46 Author: aaron Path: /home/cvs-pacman/pacman-lib Modified: TODO.aaron (1.14 -> 1.15) ------------+ TODO.aaron | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) Index: pacman-lib/TODO.aaron diff -u pacman-lib/TODO.aaron:1.14 pacman-lib/TODO.aaron:1.15 --- pacman-lib/TODO.aaron:1.14 Wed Jan 31 03:10:01 2007 +++ pacman-lib/TODO.aaron Wed Feb 7 13:09:46 2007 @@ -1,5 +1,13 @@ == This is my custom TODO file == +* Dan and I both have personal TODOs. Perhaps we should kill off TODO and + TODO.autoconf + +* Look into other VCSs to use. The main CVS repo will remain, but having a + distributed system to allow for easy patching/pushing/pulling would be nice + - monotone and mercurial look like the top contenders in my book, but I need + to evaluate both a bit more. + * Make sure all the alpm_list_t changes are valid (especially alpm_list_free) * src/pacman: @@ -41,6 +49,28 @@ * pacman: fixup doxygen documentation for public interface +* libalpm: just because a function is in alpm.h doesn't mean it needs to be in + alpm.c - we should move functions around where they should be. In fact, + alpm.c might not be needed at all, if things were organized properly. + +* feature for 3.1: package file hooks * + I've been planning on this one for some time. Here's a simple rundown: + in /etc/pacman.d/hooks: + Hook /usr/include/* : /usr/bin/ctags -R /usr/include/*.h -f /usr/include/systags + This will allow us to make "global hooks" to simplify a lot of repetitive + install files (scrollkeeper, depmod, etc). This also allows us to move + ldconfig out of pacman entirely. + possible: /etc/pacman.hooks/* files for hooks, so packages can add them too + +* feature for 3.1: multiple search/match types + option: MatchType regex (current way) + MatchType fnmatch (use fnmatch to match things like 'pacman -S gnome*') + MatchType plain (no matching. expect plain text). + +* 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. + **** BUGS **** * Removal of conflicts on -A and -U (INCOMPLETE) * gensync: get all info from packages instead of PKGBUILDs
2007/2/7, Aaron Griffin <aaron@archlinux.org>:
+* libalpm: just because a function is in alpm.h doesn't mean it needs to be in + alpm.c - we should move functions around where they should be. In fact, + alpm.c might not be needed at all, if things were organized properly.
This is exactly how SDL and Allegro (multimedia and game libraries) are organized.
+* 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.
I suggest to take a look at FreeType's ftjam. -- Roman Kyrylych (Роман Кирилич)
On 2/7/07, Aaron Griffin <aaron@archlinux.org> wrote:
+* Dan and I both have personal TODOs. Perhaps we should kill off TODO and + TODO.autoconf
And/or move all TODO files into a TODO/ directory. I did this in my local repo, which is a lot easier with anything other than CVS.
+* Look into other VCSs to use. The main CVS repo will remain, but having a + distributed system to allow for easy patching/pushing/pulling would be nice + - monotone and mercurial look like the top contenders in my book, but I need + to evaluate both a bit more.
Obviously I agree with this. They work so much better when making independent changesets, and allow for much more intelligent merging. I still need to look into mercurial a bit more.
+* libalpm: just because a function is in alpm.h doesn't mean it needs to be in + alpm.c - we should move functions around where they should be. In fact, + alpm.c might not be needed at all, if things were organized properly.
I think reducing the number of source files could be a good thing- makes the project a lot less intimidating.
+* feature for 3.1: package file hooks * + I've been planning on this one for some time. Here's a simple rundown: + in /etc/pacman.d/hooks: + Hook /usr/include/* : /usr/bin/ctags -R /usr/include/*.h -f /usr/include/systags + This will allow us to make "global hooks" to simplify a lot of repetitive + install files (scrollkeeper, depmod, etc). This also allows us to move + ldconfig out of pacman entirely. + possible: /etc/pacman.hooks/* files for hooks, so packages can add them too
Makes a lot of sense.
+* 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.
I just ran across cmake the other day. Not real familiar with it, but looks promising as it still includes capabilities for building libraries although it is much less complex than autotools. I noted that in my TODO as well. -Dan
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? Jürgen
2007/2/7, Jürgen Hötzel <juergen@hoetzel.info>:
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?
They are crap, IMHO. :p /me likes ftjam. cmake is harder and heavier, and produce native makefiles. -- Roman Kyrylych (Роман Кирилич)
On Wed, Feb 07, 2007 at 09:29:02PM +0200, Roman Kyrylych wrote:
2007/2/7, Jürgen Hötzel <juergen@hoetzel.info>:
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?
They are crap, IMHO. :p
This is exactly the response I expected ;) Jürgen
On 2/7/07, Jürgen Hötzel <juergen@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.
2007/2/7, Aaron Griffin <aaronmgriffin@gmail.com>:
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. Well, while cmake and scons are just powerful high-level wrappers to native makefiles, jam is direct replacement for make, but with better features, cleaner syntax and is easier to use. Of course this is just my personal opinion.
-- Roman Kyrylych (Роман Кирилич)
On Wed, Feb 07, 2007 at 01:46:06PM -0600, Aaron Griffin wrote:
On 2/7/07, Jürgen Hötzel <juergen@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 utilizes autotools. Jürgen
Na Wed, Feb 07, 2007 at 11:42:52PM +0100, Jürgen Hötzel <juergen@hoetzel.info> pisal(a):
GNU autotools is the defacto standard build system and other developers/distributions will more likely adopt adopt libpacman if it utilizes autotools.
"Technically, nothing. It's more personal" you lost the argument here, since decions here are not technical, but personal ;) of course, maybe it's fun to waste time to flame for nothing :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On Thu, Feb 08, 2007 at 12:19:36AM +0100, VMiklos wrote:
Na Wed, Feb 07, 2007 at 11:42:52PM +0100, Jürgen Hötzel <juergen@hoetzel.info> pisal(a):
GNU autotools is the defacto standard build system and other developers/distributions will more likely adopt adopt libpacman if it utilizes autotools.
"Technically, nothing. It's more personal"
you lost the argument here, since decions here are not technical, but personal ;)
of course, maybe it's fun to waste time to flame for nothing :)
Yes, and even "believed to be lost" contributors come back by this thread ;)
Na Thu, Feb 08, 2007 at 12:43:45AM +0100, Jürgen Hötzel <juergen@hoetzel.info> pisal(a):
Yes, and even "believed to be lost" contributors come back by this thread ;)
sure, this list is far better than any yellow press i could buy udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On Thu, Feb 08, 2007 at 12:47:46AM +0100, VMiklos wrote:
Na Thu, Feb 08, 2007 at 12:43:45AM +0100, Jürgen Hötzel <juergen@hoetzel.info> pisal(a):
Yes, and even "believed to be lost" contributors come back by this thread ;)
sure, this list is far better than any yellow press i could buy
Yellow press depends on celebrities like you VMiklos ;))
participants (6)
-
Aaron Griffin
-
Aaron Griffin
-
Dan McGee
-
Jürgen Hötzel
-
Roman Kyrylych
-
VMiklos