tech-pkg archive

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

Re: Reducing the number of patches in pkgsrc



> On Mon, Jan 07, 2008 at 07:47:08PM +0200, Aleksey Cheusov wrote:
 >> Conclusion: The Right Thing To Do (TM) is to ask upstream maintainer
 >> to NOT use autoshit at all ;-) Autoconf and automake are too hard to
 >> most developers. They are overdesigned, are based upon bad idea etc.

> The alternatives are in most cases not better.
> The only alternative I have seen so far that doesn't create more
> issues than autotools is cmake.

automake:
I'm quite new to BSD make but I really like its "libraries":
like bsd.prog.mk, bsd.lib.mk and others. Not every aspect of it but
idea in general.  I hate code generation as an idea. Both autoconf and
automake GENERATE only TONS of problems. That is bmake is good replacement
for automake.

autoconf:
What about 'pre make kit' aka pmk?
I don't know how good they are for cross compilation but they should
be good I think.

libtool:
 I have nothing against it. Good tool. But when BSD make is used (or
something that uses library idea), it is just not necessary,
i.e. platform's bsd.*.mk knows better how to build shared library, static
library, how to install .so or .dll+.lib etc. etc.

I don't see any advantages of autotools.

> The problem is not that autotools is hard to use. The problem is
> that most developers simply don't care about anything but Linux.
Just invite them to pkgsrc-pbulk mailing list.
This is a mission of pkgsrc :-)

P.S.
One of the reason I use pkgsrc is its declarative nature, i.e. most of
content of Makefile is declarative, not imperative. Just like bsd.*.mk
files.  This is why I ask for INST_* feature. INST_* statements look
much better than
.for i in x y z
   ${INSTALL} xxx yyy
.endif clauses

IMHO precisely declarative nature of pkgsrc makes it much easier for
use than rpm .specs and debian/rules.

-- 
Best regards, Aleksey Cheusov.



Home | Main Index | Thread Index | Old Index