From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 1 Jul 2002 04:31:14 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 259 ************************************************** Sunday 30 June 2002 Number 259 ************************************************** Subjects for today 1 Re: Texinfo bug - no! m4 bug (RTFM) : John Poltorak 2 Rebuilding Info docs : John Poltorak 3 Wget build bug ? : John Poltorak 4 Re: Wget build bug ? : csaba.raduly at sophos.com 5 Re: Rebuilding Info docs : csaba.raduly at sophos.com 6 Re: Wget build bug ? : John Poltorak 7 Odd things happening in Makefile : John Poltorak 8 Re: Rebuilding Info docs : John Poltorak 9 Re: UnixOS/2 Build System : Thomas Hoffmann 10 Re: Texinfo bug - no! m4 bug (RTFM) : Thomas Hoffmann 11 Re: Wget build bug ? : Andreas Buening 12 Re: UnixOS/2 Build System : John Poltorak 13 Re: Wget build bug ? : John Poltorak 14 Re: Rebuilding Info docs : John Poltorak **= Email 1 ==========================** Date: Mon, 1 Jul 2002 10:27:35 +0100 From: John Poltorak Subject: Re: Texinfo bug - no! m4 bug (RTFM) On Sun, Jun 30, 2002 at 12:57:06PM +0100, Thomas Hoffmann wrote: > Folks, > you have described at length the phenomenology of this so called bug, > but nobody seems to have bothered to have a look at text of the error > msg. Otherwise, you would have found in m4.texinfo line 282 and 352: > > 282: at xref{Compatibility} for more details. > 352: functions. at xref{Debug Levels} for more details on the format and > > As you can see, "for" follows the at xref command (...and begins with the > "f" from the "not f" part of the error msg. Thanks for looking at this bug correctly. I guess we assume that any bugs which come to light can't be in the original app. > Now a look into the texinfo docs provides: > > *Please note:* A period or comma *must* follow the closing brace > of an ` at xref'. It is required to terminate the cross reference. > This period or comma will appear in the output, both in the Info > file and in the printed manual. > > So, to fix this one simply should add the needed periods or commata in > m4.texinfo (m4 "bug" is a bit of an exaggeration, maybe the texinfo > syntax has changed. But the above paragraph can already be found in > texi.tex in emx's gnudoc.zip from 1995). m4.texinfo originates from 1994, so it isn't easy to know if this warning msg would have appeared at the time. I'm not really sure whether Make ought to be rebuilding any .info docs if they are included in an archive... > -- > Thomas Hoffmann Telephone: > 49-351-4598831 > thoffman at zappa.sax.de Dresden, > Germany > > ..sig under construction ... -- John **= Email 2 ==========================** Date: Mon, 1 Jul 2002 10:35:56 +0100 From: John Poltorak Subject: Rebuilding Info docs Is there any way, when rebuilding an app by running configure and make, of preventing the rebuild of any info docs when they already exist as part of the archive? I would suggest using the original build of these docs if possible, when assembling a UnixOS/2 package. Any comments?... -- John **= Email 3 ==========================** Date: Mon, 1 Jul 2002 11:15:04 +0100 From: John Poltorak Subject: Wget build bug ? Wget seems to differ from every other GNU app I've tried to build in a couple of ways. Wonder if anyone can confirm whether this is a bug in build files... In each case I run autoconf to rebuild configure, and then configure. With WGET (v1.8.2) the config.log shows the path as:- PATH: c PATH: /usr/bin;c PATH: /emx/bin;c PATH: /usr/local/bin;c PATH: /os2; every other app has it as:- PATH: c:/usr/bin PATH: c:/emx/bin PATH: c:/usr/local/bin PATH: c:/os2 PATH: . Also, WGET is the only app where the check:- checking for a BSD-compatible install results in:- ./install-sh -c everything else finds:- c:/usr/bin/install.exe -c Does anyone know why this happens? Why should WGET act differently to everything else? -- John **= Email 4 ==========================** Date: Mon, 1 Jul 2002 12:35:48 +0100 From: csaba.raduly at sophos.com Subject: Re: Wget build bug ? On 01/07/2002 11:15:04 owner-os2-unix wrote: >Wget seems to differ from every other GNU app I've tried to build in a >couple of ways. Wonder if anyone can confirm whether this is a bug in >build files... > >In each case I run autoconf to rebuild configure, and then configure. With >WGET (v1.8.2) the config.log shows the path as:- > > >PATH: c >PATH: /usr/bin;c >PATH: /emx/bin;c >PATH: /usr/local/bin;c >PATH: /os2; > That's a clear sign that configure used : instead of ; as the path separator. You need to run an OS/2-aware autoconf, or convert_configure.pl [snip] > >Also, WGET is the only app where the check:- > >checking for a BSD-compatible install > >results in:- > >./install-sh -c > >everything else finds:- > >c:/usr/bin/install.exe -c > Probably due to the same problem. It can't find install.exe in the path because it chops the paths at the wrong points. -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 5 ==========================** Date: Mon, 1 Jul 2002 12:39:54 +0100 From: csaba.raduly at sophos.com Subject: Re: Rebuilding Info docs On 01/07/2002 10:35:56 owner-os2-unix wrote: >Is there any way, when rebuilding an app by running configure and make, of >preventing the rebuild of any info docs when they already exist as part of >the archive? > You probably need to at least "touch *.info" after running configure. The generated makefiles are probably written so the output files depend on the makefile. The makefile is new, so the output files are out-of-date. -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 6 ==========================** Date: Mon, 1 Jul 2002 12:46:33 +0100 From: John Poltorak Subject: Re: Wget build bug ? On Mon, Jul 01, 2002 at 12:35:48PM +0100, csaba.raduly at sophos.com wrote: > > On 01/07/2002 11:15:04 owner-os2-unix wrote: > > >Wget seems to differ from every other GNU app I've tried to build in a > >couple of ways. Wonder if anyone can confirm whether this is a bug in > >build files... > > > >In each case I run autoconf to rebuild configure, and then configure. With > >WGET (v1.8.2) the config.log shows the path as:- > > > > > >PATH: c > >PATH: /usr/bin;c > >PATH: /emx/bin;c > >PATH: /usr/local/bin;c > >PATH: /os2; > > > > That's a clear sign that configure used : instead of ; as the path > separator. > You need to run an OS/2-aware autoconf, or convert_configure.pl I ran the latest OS/2 port of Autoconf v2.53! This port has worked with everything else. Does WGET require a specific SHELL to build properly? I'll give BASH a try to see if it makes any difference. -- John **= Email 7 ==========================** Date: Mon, 1 Jul 2002 15:42:42 +0100 From: John Poltorak Subject: Odd things happening in Makefile I struggling to work out why Make is falling over while running the Makefile created in DOC while building SED. A strange thing seems to occur in this part of the Makefile:- $(srcdir)/version.texi: $(srcdir)/stamp-vti at : $(srcdir)/stamp-vti: sed.texi $(top_srcdir)/configure.in at (set `$(SHELL) $(srcdir)/mdate-sh $(srcdir)/sed.texi`; \ echo " at set UPDATED $$1 $$2 $$3"; \ echo " at set UPDATED-MONTH $$2 $$3"; \ echo " at set EDITION $(VERSION)"; \ echo " at set VERSION $(VERSION)") > vti.tmp at cmp -s vti.tmp $(srcdir)/version.texi \ || (echo "Updating $(srcdir)/version.texi"; \ cp vti.tmp $(srcdir)/version.texi) - at rm -f vti.tmp at cp $(srcdir)/version.texi $ at Before Make runs, stamp.vti contains:- at set UPDATED 28 June 1998 at set EDITION 3.02 at set VERSION 3.02 Afterwards, the current environment, as output by SET, is prepended to these lines. I'm sure this isn't supposed to occur. Can anyone see what is causing it? -- John **= Email 8 ==========================** Date: Mon, 1 Jul 2002 16:03:11 +0100 From: John Poltorak Subject: Re: Rebuilding Info docs On Mon, Jul 01, 2002 at 12:39:54PM +0100, csaba.raduly at sophos.com wrote: > > On 01/07/2002 10:35:56 owner-os2-unix wrote: > > >Is there any way, when rebuilding an app by running configure and make, of > >preventing the rebuild of any info docs when they already exist as part of > >the archive? > > > > You probably need to at least "touch *.info" after running configure. > The generated makefiles are probably written so the output files depend > on the makefile. The makefile is new, so the output files are > out-of-date. I _think_ I only need to touch stamp-vti (whatever that it... what vti stands for I don't know...) The problem is knowing when to touch it... I can pause the make process as soon as doc\makefile is built and touch stamp-vti in another session, but doing it from within a build script seems a little tricky. -- John **= Email 9 ==========================** Date: Mon, 01 Jul 2002 20:54:25 +0100 From: Thomas Hoffmann Subject: Re: UnixOS/2 Build System There are several info->(html, inf) translators available. But here, in this source-centric community I would think that using makeinfo's ability to create html from .texi is the way to go (BTW: wget, at least the package I did download, already has html docs). James Cannon schrieb: > > GNU INFO should be able to be converted to a format > more suitable to you. Perhaps other list members can > provide recommendations ... > -- Thomas Hoffmann Telephone: 49-351-4598831 thoffman at zappa.sax.de Dresden, Germany ..sig under construction ... **= Email 10 ==========================** Date: Mon, 01 Jul 2002 21:18:20 +0100 From: Thomas Hoffmann Subject: Re: Texinfo bug - no! m4 bug (RTFM) This is similar to using autoconf: Fur merely building the software you should not need to rebuild *.info or configure. But if you change something (-->fix errors in .texi, e.g.) or have a somewhat obscure OS ..... John Poltorak schrieb: > > I'm not really sure whether Make ought to be rebuilding any .info docs if > they are included in an archive... > -- Thomas Hoffmann Telephone: 49-351-4598831 thoffman at zappa.sax.de Dresden, Germany ..sig under construction ... **= Email 11 ==========================** Date: Mon, 01 Jul 2002 21:57:58 +0200 From: Andreas Buening Subject: Re: Wget build bug ? John Poltorak wrote: > > On Mon, Jul 01, 2002 at 12:35:48PM +0100, csaba.raduly at sophos.com wrote: > > > > On 01/07/2002 11:15:04 owner-os2-unix wrote: > > > > >Wget seems to differ from every other GNU app I've tried to build in a > > >couple of ways. Wonder if anyone can confirm whether this is a bug in > > >build files... > > > > > >In each case I run autoconf to rebuild configure, and then configure. With > > >WGET (v1.8.2) the config.log shows the path as:- > > > > > > > > >PATH: c > > >PATH: /usr/bin;c > > >PATH: /emx/bin;c > > >PATH: /usr/local/bin;c > > >PATH: /os2; > > > > > > > That's a clear sign that configure used : instead of ; as the path > > separator. Exactly. > > You need to run an OS/2-aware autoconf, or convert_configure.pl > > I ran the latest OS/2 port of Autoconf v2.53! Obviously the standard autoconf macros aren't executed for this package. The old versions are probably hardcoded into that package. You might get an error like "AC_blurb_bla is outdated, please run aclocal" You can try to replace all *.m4 macro files by newer ones from the /usr/share/auto* directories (candidates are files like init.m4, header.m4). If that doesn't work you have to edit acinclude.m4 or aclocal.m4 by hand. :-( > This port has worked with everything else. > > Does WGET require a specific SHELL to build properly? > > I'll give BASH a try to see if it makes any difference. Will make no difference. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Redmond where the Shadows lie. **= Email 12 ==========================** Date: Mon, 1 Jul 2002 22:28:29 +0100 From: John Poltorak Subject: Re: UnixOS/2 Build System On Mon, Jul 01, 2002 at 08:54:25PM +0100, Thomas Hoffmann wrote: > There are several info->(html, inf) translators available. But here, in > this source-centric community I would think that using makeinfo's > ability to create html from .texi is the way to go Yes, I guess we need to decide whether to include html docs as standard... I don't know if there is a way to build them automatically via a configure option, but that would be the simplest way. Does anyone know if this is possible? > (BTW: wget, at least > the package I did download, already has html docs). I don't see any in the GNU source, apart from something called download.html... > James Cannon schrieb: > > > > GNU INFO should be able to be converted to a format > > more suitable to you. Perhaps other list members can > > provide recommendations ... > > > > -- > Thomas Hoffmann Telephone: > 49-351-4598831 > thoffman at zappa.sax.de Dresden, > Germany > > ..sig under construction ... -- John **= Email 13 ==========================** Date: Mon, 1 Jul 2002 22:46:50 +0100 From: John Poltorak Subject: Re: Wget build bug ? On Mon, Jul 01, 2002 at 09:57:58PM +0200, Andreas Buening wrote: > John Poltorak wrote: > > > > On Mon, Jul 01, 2002 at 12:35:48PM +0100, csaba.raduly at sophos.com wrote: > > > > > > >In each case I run autoconf to rebuild configure, and then configure. With > > > >WGET (v1.8.2) the config.log shows the path as:- > > > > > > > > > > > >PATH: c > > > >PATH: /usr/bin;c > > > >PATH: /emx/bin;c > > > >PATH: /usr/local/bin;c > > > >PATH: /os2; > > > > > > > > > > That's a clear sign that configure used : instead of ; as the path > > > separator. > > Exactly. > > > > You need to run an OS/2-aware autoconf, or convert_configure.pl > > > > I ran the latest OS/2 port of Autoconf v2.53! > > Obviously the standard autoconf macros aren't executed > for this package. The old versions are probably hardcoded > into that package. Is there any prospect of getting that changed? > You might get an error like > "AC_blurb_bla is outdated, please run aclocal" > You can try to replace all *.m4 macro files by newer ones > from the /usr/share/auto* directories (candidates are > files like init.m4, header.m4). If that doesn't work you > have to edit acinclude.m4 or aclocal.m4 by hand. :-( The package only includes one *.m4 file - aclocal.m4 and it looks like a bit of a monster. I wonder if the WGET maintainers have any intention to auto generate it with aclocal in the future... > bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Redmond where the Shadows lie. **= Email 14 ==========================** Date: Mon, 1 Jul 2002 22:56:49 +0100 From: John Poltorak Subject: Re: Rebuilding Info docs On Mon, Jul 01, 2002 at 04:03:11PM +0100, John Poltorak wrote: > On Mon, Jul 01, 2002 at 12:39:54PM +0100, csaba.raduly at sophos.com wrote: > > > > On 01/07/2002 10:35:56 owner-os2-unix wrote: > > > > >Is there any way, when rebuilding an app by running configure and make, of > > >preventing the rebuild of any info docs when they already exist as part of > > >the archive? > > > > > > > You probably need to at least "touch *.info" after running configure. > > The generated makefiles are probably written so the output files depend > > on the makefile. The makefile is new, so the output files are > > out-of-date. > > > I _think_ I only need to touch stamp-vti (whatever that it... what vti > stands for I don't know...) > > The problem is knowing when to touch it... I can pause the make process as > soon as doc\makefile is built and touch stamp-vti in another session, but > doing it from within a build script seems a little tricky. I found this sequence seems to work OK - at least for SED....:- configure touch doc/stamp-vti make I got these msgs:- Making all in doc make[2]: Entering directory `C:/unixos2/workdir/sed-3.02/doc' make[2]: Leaving directory `C:/unixos2/workdir/sed-3.02/doc' I was surprised not see something like 'Nothing to do'... -- John