Subject: Re: pkg/18556
To: None <wiz@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: netbsd-bugs
Date: 10/06/2002 18:53:31
[ On , October 6, 2002 at 21:43:47 (-0000), wiz@netbsd.org wrote: ]
> Subject: Re: pkg/18556
>
> Synopsis: new pkgsrc mk/auto{conf,make}.mk should do more by default
> 
> State-Changed-From-To: open->closed

You're a little quick off the mark here.  If you don't agree with these
things I'd much more appreciate 'feedback' be set and a discussion
opened in tech-pkg.  I wouldn't have made this a PR if I didn't think it
was important.  I'll repost this reply to tech-pkg if you feel that's
appropriate.

> State-Changed-By: wiz
> State-Changed-When: Sun Oct 6 14:40:16 PDT 2002
> State-Changed-Why: 
> I disagree about USE_GMAKE -- it's perfectly possible to make the
> output of automake parsable by BSD make.

Nope, not true, and especially not true with modern automake (1.6 and
newer).  The problems are subtle and don't always show up in every build
using automake, but they are common enough to warrant always using
gmake.

I suppose you might get away without gmake for automake-1.4 only, but I
really don't see any reason to be so picky, and there are some noticable
advantages to using gmake with even automake-1.4 in some situations for
some packages.

If you're going to run GNU automake then requiring GNU make is a pretty
obvious outcome.

> I also disagree about the pre-configure target -- I took a good
> look at all packages using automake.mk when I converted them, and
> this is just not even the most common case.

That's part of the problem.  It should be the common case.  Most of the
existing packages including automake patches are using home grown hacks
to re-run automake.  The proper procedure is very well defined and only
in extremely rare cases will any customisation really be necessary.

Half the per-package hacks in place now don't even do proper error
checking of the commands, and some don't even do all the right things in
the right order for some versions of autoconf and they work only by
accident!

> GNU_CONFIGURE could be set, I agree, but in this case I just prefer
> if the package creator has to set it manually; after all, automake.mk
> is just a crutch, and at least I hope it's not included after the next
> update of the package, which would just delay the manual setting
> of GNU_CONFIGURE.

GNU_CONFIGURE must be set somewhere when you're configuring packages
using GNU Autoconf.  It's much better to force it on when we know 100%
for certain that it must be true.  The package makefiles can still set
it themselves for documentation purposes, but my interest is mostly in
making it actually work properly all of the time even if the package
makefile isn't so explicit.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>