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

Re: [leafnode-list] ANNOUNCEMENT: leafnode 1.9.16ma1



Cornelius Krasel schrieb am Mittwoch, den 09. August 2000:

> Matthias Andree wrote:
> 
> > I'm announcing leafnode 1.9.16ma1 (beta release).
> > 
> > This version has no features or bugfixes over leafnode 1.9.16, but it
> > drops its local PCRE library
> 
> Just out of curiosity: why? The reason that PCRE is included is twofold:
> first, it avoids complaints of newbies that leafnode won't compile, and
> second, if a shared PCRE library is already installed, leafnode will
> use it anyway. The only advantage that I can see is that the tarball
> is smaller without PCRE.

Hey, leafnode using a pre-installed libpcre.so.* is a reason to rip pcre
off of leafnode :-)

Many distributions come with PCRE (SuSE) or offer PCRE as contribution
(RedHat, see http://www.redhat.com/swr/i386/pcre-3.2-1.i386.html)
package.

I can contribute a perl script that downloads and installs PCRE if you
like.

The procedure to build and install PCRE or Leafnode from source does not
differ, but cutting the distribution to half is size is useful. If
people get and install the leafnode RPM, they can get and install the
PCRE RPM as well. Don't bloat.

> Other than that, I like the --with-libdir and similar switches. I don't
> like automake, but that's probably my own bad taste (IMO, automake
> produces completely illegible Makefiles).

You're not supposed to read automatically generated Makefiles :-)

Seriously, the whole Makefile hassle boils down to what Makefile.am
says. Makefile.in and Makefile are auto-generated. You can drop in your
own rules much like in Makefile.in (which is what I'm doing for the
install: target), the user does not need any of these packages
installed, just the usual set of things he needs anyways (sed, awk etc.)

_Please_ have a look at the contained Makefile.am.

Using automake has several advantages, among them a _simple_ way to
achieve GNUish behaviour, feature extraction from configure.in,
automatic insertion of the proper libraries to link against that have
been checked for in configure.in and others.

Note that my package *also* inserts the proper paths into the man pages
(configure.in actually does that). I forgot to mention that in my
previous post.

I find the Makefile.am style of doing things VERY attractive, example:

------------------------------------------------------------------------
sbin_PROGRAMS=leafnode fetchnews texpire checkgroups applyfilter lsort

[...]

leafnode_SOURCES=nntpd.c leafnode.h
LDADD=liblnutil.a

noinst_LIBRARIES=liblnutil.a
liblnutil_a_SOURCES=nntputil.c configutil.c xoverutil.c activutil.c \
        miscutil.c artutil.c filterutil.c config.c
------------------------------------------------------------------------

That means: leafnode depends on nntpd.c and leafnode.h, you link it
against liblnutil.a, liblnutil is not installed, what files go into
liblnutil, and leafnode is installed into sbin. Renaming a program is a
matter of changing two words in Makefile.am.

Now, could you give a more detailed description of your objections
against automake? Just curiosity, no offense.

-- 
Matthias Andree

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list