* config.modules glitch in configure or make dependencies @ 2002-09-11 14:20 Bart Schaefer 2002-09-12 9:37 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Bart Schaefer @ 2002-09-11 14:20 UTC (permalink / raw) To: zsh-workers I just noticed that my last several recompiles have failed to generate a config.modules line for zsh/net/socket. I had to remove config.modules and re-run config.status before it showed up. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.modules glitch in configure or make dependencies 2002-09-11 14:20 config.modules glitch in configure or make dependencies Bart Schaefer @ 2002-09-12 9:37 ` Peter Stephenson 2002-09-12 14:58 ` Bart Schaefer 0 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 2002-09-12 9:37 UTC (permalink / raw) To: Zsh hackers list "Bart Schaefer" wrote: > I just noticed that my last several recompiles have failed to generate a > config.modules line for zsh/net/socket. I had to remove config.modules > and re-run config.status before it showed up. I think this is deliberate. You're supposed to run `make prep' when you add a new module. Otherwise, it has no way of generating dependency information --- a normal `make' won't do that in most build systems I'm familiar with. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.modules glitch in configure or make dependencies 2002-09-12 9:37 ` Peter Stephenson @ 2002-09-12 14:58 ` Bart Schaefer 2002-09-13 9:18 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Bart Schaefer @ 2002-09-12 14:58 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list On Sep 12, 10:37am, Peter Stephenson wrote: } Subject: Re: config.modules glitch in configure or make dependencies } } "Bart Schaefer" wrote: } > I just noticed that my last several recompiles have failed to generate a } > config.modules line for zsh/net/socket. } } I think this is deliberate. You're supposed to run `make prep' when } you add a new module. Hm. But ... I applied Clint's zsh/db module patch and just ran "make" and that one correctly got picked up and included in config.modules. And then I applied the patch in reverse (because I don't have libdb-4, and I was only testing whether it would correctly omit the module in that case, which it doesn't) and ran "make" again, and zsh/db vanished. The config.modules code in zshconfig.ac does for modfile in `cd ${srcdir}; echo */*.mdd */*/*.mdd`; do so I'm baffled as to why that needs "make prep". Note that I'm not complaining that the module didn't get compiled (that is, that Makemod was not up to date -- I know "make prep" runs mkmakemod), but that it didn't even get _mentioned_ in config.modules. It's entirely likely that this is just something I'm missing and not really a glitch, but I don't think "make prep" is the culprit. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.modules glitch in configure or make dependencies 2002-09-12 14:58 ` Bart Schaefer @ 2002-09-13 9:18 ` Peter Stephenson 2002-09-13 15:46 ` Bart Schaefer 0 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 2002-09-13 9:18 UTC (permalink / raw) To: Zsh hackers list "Bart Schaefer" wrote: > The config.modules code in zshconfig.ac does > > for modfile in `cd ${srcdir}; echo */*.mdd */*/*.mdd`; do > > so I'm baffled as to why that needs "make prep". But this only runs if configure or config.status is run, and this doesn't happen every make. Sometimes a new module also alters one of the configure files; then the top-level Makefile will pick up that things have changed and run this code. There is no direct dependency *simply* on piling in some extra .mdd files. I would guess socket didn't need to change the configure stuff, but db did. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.modules glitch in configure or make dependencies 2002-09-13 9:18 ` Peter Stephenson @ 2002-09-13 15:46 ` Bart Schaefer 2002-09-13 15:57 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Bart Schaefer @ 2002-09-13 15:46 UTC (permalink / raw) To: Zsh hackers list On Sep 13, 10:18am, Peter Stephenson wrote: } Subject: Re: config.modules glitch in configure or make dependencies } } "Bart Schaefer" wrote: } > The config.modules code in zshconfig.ac does } > } > for modfile in `cd ${srcdir}; echo */*.mdd */*/*.mdd`; do } } But this only runs if configure or config.status is run Aha. The actual problem is that this *isn't* done if config.status is run -- it's only done if *configure* is run, which running config.status only sometimes causes to happen. In most cases config.status regenerates only those files that result from processing a .in. Consider the following patch; configure writes config.modules.sh and also arranges that config.status will source it, and then sources it. This has the added benefit that one can run config.modules.sh at any time to change the module configuration, rather than having to re-run a full configure. Index: zshconfig.ac =================================================================== RCS file: /extra/cvsroot/zsh/zsh-4.0/zshconfig.ac,v retrieving revision 1.14 diff -c -r1.14 zshconfig.ac --- zshconfig.ac 25 May 2002 18:05:54 -0000 1.14 +++ zshconfig.ac 13 Sep 2002 15:41:03 -0000 @@ -1,5 +1,5 @@ dnl -dnl configure.in: Configure template for zsh. +dnl zshconfig.ac: Configure template for zsh. dnl Process this file with autoconf to produce a configure script. dnl dnl Copyright (c) 1995-1997 Richard Coleman @@ -1898,9 +1898,15 @@ # level subdirectories. Any existing line not containing 'auto=y' will be # retained, provided the .mdd file itself was found. CONFIG_MODULES=./config.modules +cat <<EOM > ${CONFIG_MODULES}.sh +srcdir="$srcdir" +dynamic="$dynamic" +CONFIG_MODULES="${CONFIG_MODULES}" +EOM +cat <<\EOM >> ${CONFIG_MODULES}.sh echo "creating ${CONFIG_MODULES}" userlist=" " -if test -f config.modules; then +if test -f ${CONFIG_MODULES}; then userlist="`sed -e '/^#/d' -e '/auto=y/d' -e 's/ .*/ /' -e 's/^name=/ /' \ ${CONFIG_MODULES}`" mv ${CONFIG_MODULES} ${CONFIG_MODULES}.old @@ -1986,6 +1992,11 @@ fi done) >${CONFIG_MODULES} rm -f ${CONFIG_MODULES}.old +EOM +AC_OUTPUT_COMMANDS([if test -z "$CONFIG_FILES$CONFIG_HEADERS"; then + . ./${CONFIG_MODULES}.sh +fi]) +. ./${CONFIG_MODULES}.sh CLEAN_MK="${srcdir}/Config/clean.mk" CONFIG_MK="${srcdir}/Config/config.mk" @@ -1999,7 +2010,7 @@ AC_SUBST_FILE(VERSION_MK)dnl AC_OUTPUT(Config/defs.mk Makefile Doc/Makefile Etc/Makefile Src/Makefile \ -Test/Makefile, \ +Test/Makefile, [test -z "$CONFIG_HEADERS" || echo > stamp-h]) eval "zshbin1=${bindir}" Index: Makefile.in =================================================================== RCS file: /extra/cvsroot/zsh/zsh-4.0/Makefile.in,v retrieving revision 1.5 diff -c -r1.5 Makefile.in --- Makefile.in 5 Sep 2001 15:22:28 -0000 1.5 +++ Makefile.in 13 Sep 2002 15:30:19 -0000 @@ -144,7 +144,7 @@ @CLEAN_MK@ distclean-here: - rm -f Makefile config.h config.status config.log config.cache config.modules stamp-h Config/defs.mk + rm -f Makefile config.h config.status config.log config.cache config.modules config.modules.sh stamp-h Config/defs.mk realclean-here: cd $(sdir) && rm -f config.h.in stamp-h.in configure -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.modules glitch in configure or make dependencies 2002-09-13 15:46 ` Bart Schaefer @ 2002-09-13 15:57 ` Peter Stephenson 2002-09-13 17:53 ` Bart Schaefer 0 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 2002-09-13 15:57 UTC (permalink / raw) To: Zsh hackers list "Bart Schaefer" wrote: > Consider the following patch; configure writes config.modules.sh and also > arranges that config.status will source it, and then sources it. Well, it's about the only bit of the configuration not yet done in (at least) two stages, so I don't see why it shouldn't share the pain. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.modules glitch in configure or make dependencies 2002-09-13 15:57 ` Peter Stephenson @ 2002-09-13 17:53 ` Bart Schaefer 2002-09-13 18:31 ` Clint Adams 0 siblings, 1 reply; 9+ messages in thread From: Bart Schaefer @ 2002-09-13 17:53 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list On Sep 13, 4:57pm, Peter Stephenson wrote: } Subject: Re: config.modules glitch in configure or make dependencies } } "Bart Schaefer" wrote: } > Consider the following patch; configure writes config.modules.sh and also } > arranges that config.status will source it, and then sources it. } } Well, it's about the only bit of the configuration not yet done in (at } least) two stages, so I don't see why it shouldn't share the pain. It's not really two stages; the code still executes at the same time it always did, it just happens to be in two files. If you prefer, it could be written like this: AC_OUTPUT_COMMANDS(,[if test -z "\$CONFIG_FILES\$CONFIG_HEADERS"; then `cat ./${CONFIG_MODULES}.sh && rm -f ./${CONFIG_MODULES}.sh` fi]) . ./${CONFIG_MODULES}.sh That actually copies the code from configure into config.status, so that the .sh file doesn't have to be left behind. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.modules glitch in configure or make dependencies 2002-09-13 17:53 ` Bart Schaefer @ 2002-09-13 18:31 ` Clint Adams 2002-09-13 22:47 ` Bart Schaefer 0 siblings, 1 reply; 9+ messages in thread From: Clint Adams @ 2002-09-13 18:31 UTC (permalink / raw) To: Bart Schaefer; +Cc: Peter Stephenson, Zsh hackers list > It's not really two stages; the code still executes at the same time it > always did, it just happens to be in two files. If you prefer, it could > be written like this: > > AC_OUTPUT_COMMANDS(,[if test -z "\$CONFIG_FILES\$CONFIG_HEADERS"; then > `cat ./${CONFIG_MODULES}.sh && rm -f ./${CONFIG_MODULES}.sh` > fi]) > . ./${CONFIG_MODULES}.sh Maybe this stuff could be handled by a Src/Modules/configure that also handles the extra lib dependencies. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.modules glitch in configure or make dependencies 2002-09-13 18:31 ` Clint Adams @ 2002-09-13 22:47 ` Bart Schaefer 0 siblings, 0 replies; 9+ messages in thread From: Bart Schaefer @ 2002-09-13 22:47 UTC (permalink / raw) To: Zsh hackers list On Sep 13, 2:31pm, Clint Adams wrote: > > Maybe this stuff could be handled by a Src/Modules/configure that also > handles the extra lib dependencies. That's wouldn't make any difference in this case, unless we completely changed the way modules are configured so as to have a config.modules.in file and use @@name@@ replacements. Otherwise it'd just be relocating the problem from the top-level configure to the subdir one. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-09-13 22:48 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-09-11 14:20 config.modules glitch in configure or make dependencies Bart Schaefer 2002-09-12 9:37 ` Peter Stephenson 2002-09-12 14:58 ` Bart Schaefer 2002-09-13 9:18 ` Peter Stephenson 2002-09-13 15:46 ` Bart Schaefer 2002-09-13 15:57 ` Peter Stephenson 2002-09-13 17:53 ` Bart Schaefer 2002-09-13 18:31 ` Clint Adams 2002-09-13 22:47 ` Bart Schaefer
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).