PATCH [multi-env]: 4 mini patches for the build scripts

[Max Kellermann <ma...@duempel.org>]

4 mini patches which add minor improvements to the build scripts:

01-fix_header_name.patch
- make xsbuilder.pl work (no real glue updates)

02-run_xsbuilder_pl_from_configure.patch
- imho, xsbuilder.pl should be run at the end of configure, not from
  buildconf

03-remove_redundant_xsbuilder_check.patch
- ExtUtils::XSBuilder is checked in both buildconf and configure;
  buildconf should only prepare the autoconf/automake scripts,
  configure is for the real checks, isn't it?

04-verbose_check_messages.patch
- show pretty autoconf messages while checking the glue dependencies

Max

Re: PATCH [multi-env]: 4 mini patches for the build scripts

[Max Kellermann <ma...@duempel.org>]

On 2005/02/06 19:29, Joe Schaefer <jo...@sunstarsys.com> wrote:
> And besides, I think it may be too much work to maintain the
> parse-source stuff in a platform-independent way (in fact, I'm not
> sure how Randy rolls the Win32 packages anymore, so it may be
> non-portable already).

I see, I didn't know that doesn't work on windows. Although that slows
down configure, it seems logical to me to let configure do that.

Is libapreq2 built with cygwin on windows?

Max

Re: PATCH [multi-env]: 4 mini patches for the build scripts

[Joe Schaefer <jo...@sunstarsys.com>]

Max Kellermann <ma...@duempel.org> writes:

> 4 mini patches which add minor improvements to the build scripts:
>
> 01-fix_header_name.patch
> - make xsbuilder.pl work (no real glue updates)

+1.

> 02-run_xsbuilder_pl_from_configure.patch
> - imho, xsbuilder.pl should be run at the end of configure, not from
>   buildconf

This may not be a good idea.  For one thing it reverts
part of this CHANGES item:

- Build system [joes]
  Add --with-apache2-httpd option so users can override apxs's
  notion of where the httpd executable is.  XSBuilder's header
  parser runs from buildconf now instead of configure, so we
  will include those tables in the release tarball.  buildconf
  gets an additional --with-perl option for running the xsbuilder.pl
  parsing script.  The XS generation code in xsbuilder.pl has moved 
  to glue/perl/Makefile.PL.

The reason I made that change is because the modperl guys
we're getting tired of seeing a parse-source scan on every
reconfig.  And besides, I think it may be too much work to
maintain the parse-source stuff in a platform-independent 
way (in fact, I'm not sure how Randy rolls the Win32 packages 
anymore, so it may be non-portable already).

So we decided to generate the xs tables and include 
them in our releases, similar to what mp2 has done.  
That's why xsbuilder.pl now runs from buildconf instead 
of configure.

> 03-remove_redundant_xsbuilder_check.patch
> - ExtUtils::XSBuilder is checked in both buildconf and configure;
>   buildconf should only prepare the autoconf/automake scripts,
>   configure is for the real checks, isn't it?

We use ExtUtils::XSBuilder twice.  First, to parse the C
headers into glue/perl/xsbuilder/tables (which IMO should 
run from buildconf). Second, to populate the glue/perl/xs 
directory from those tables.  This second step is currently
done at compile-time (during make), so we need a configure-time
prereq check to ensure users have ExtUtils::XSBuilder installed.
If anything, I'd like to see that prereq go away, so finding
a way to move the second usage (xs generation) into ./buildconf 
is a good idea I think. But moving the first usage (parse-source)
back to configure isn't a good idea, IMO.

> 04-verbose_check_messages.patch
> - show pretty autoconf messages while checking the glue dependencies

Cool!
-- 
Joe Schaefer