zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: "Zsh hackers list" <zsh-workers@sunsite.dk>
Subject: Re: autoconf 2.5 (Re: PATCH: terminfo horor)
Date: Thu, 08 Jan 2004 13:25:41 +0100	[thread overview]
Message-ID: <7407.1073564741@gmcs3.local> (raw)
In-Reply-To: <66F451E8923A3D42B22434287141E2E3C675A5@mowp006a.ru001.siemens.net>

On 25 Dec, Andrey wrote:

> - autoconf 2.5 does not create anything in configure. Instead the sole point
> of configure script is to create config.status - and it is config.status
> that finally does (should do) the job of creating files, making
> substitutions etc

Taking that, what we should probably do is have configure not create
any config.modules files but have it do the work of config.modules.sh,
putting the results directly into config.status in such a way that
config.status will create the config.modules file.

> What I intended was to allow modules to supply "configure plugins" to make
> whatever checks are needed; then configure could simply emit list modules to
> build without generating (mostly identical) makefile fragments for every
> module. Hmm ... it does look suspiciously similar to linux kernel, does not
> it? :)
> 
> But it is near to impossible to create such plugins as shell scripts
> (autoconf simply does not support it).
> 
> What is possible is to provide configure snippets and make Util/preconfig to
> generate modules.m4 that includes them' modules.m4 would then be included by
> zshconfig.ac. Unfortunately it is not easy to handle dependencies (i.e.
> module added or removed after modules.m4 has been created). 

I don't know much about how the linux kernel handles things. The idea
of having configure snippets that are included as part of zshconfig.ac
sounds good. Would allow us to separate out configure tests that are
specific to a module.

Peter wrote:
> Can someone confirm this is a suitable patch for removing support for
> old versions of autoconf, together with deleting configure.in which I
> will commit at the same time?

That does solve the problem I had because config.status no longer
writes out a crap config.modules. Only trouble is that, as Bart points
out, those lines are needed when someone runs just config.status.

I suggest you go ahead with the rest of the patch. Except there's a
typo (arlier) and you could also merge zshconfig.ac into configure.ac -
there's no need for a separate file.

Oliver


  reply	other threads:[~2004-01-08 12:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-25 11:49 Borzenkov Andrey
2004-01-08 12:25 ` Oliver Kiddle [this message]
2004-01-08 13:15   ` Peter Stephenson
  -- strict thread matches above, loose matches on Subject: below --
2004-01-15  8:36 Borzenkov Andrey
2004-01-09  9:31 Borzenkov Andrey
2004-01-14 16:01 ` Oliver Kiddle
2004-01-14 16:24   ` Peter Stephenson
2004-01-08 15:20 Borzenkov Andrey
2004-01-08 16:11 ` Oliver Kiddle
2003-12-25 12:17 Borzenkov Andrey
2004-01-05 12:34 ` Peter Stephenson
2003-12-18 17:05 PATCH: terminfo horor Peter Stephenson
2003-12-19  8:59 ` autoconf 2.5 (Re: PATCH: terminfo horor) Oliver Kiddle
2003-12-19 11:14   ` Peter Stephenson
2003-12-19 12:41     ` Mads Martin Joergensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7407.1073564741@gmcs3.local \
    --to=okiddle@yahoo.co.uk \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).