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